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1.@ INTRODUCTION 


This document describes the functions, operation, and message formats 
of the Data Access Protocol (DAP). The document is primarily intended 
to assist those who implement DAP in understanding how DAP functions 
within a system. The document does not address specific 
implementations. 


DAP performs remote file access via a file system such as_ Record 
Management Services (RMS). Unit Record Devices and terminals can be 
accessed if supported by a file system. When Unit Record Devices’ and 
terminals are supported by a file system in a device-dependent manner, 
the device control features peculiar to the individual devices are not 
Supported by DAP. 


DAP is one of the protocols of the DIGITAL Network Architecture (DNA). 
DNA models the software (or hardware) for DECnet implementations. 
DECnet is a family of software modules, data bases, and hardware 
components typically used to tie DIGITAL systems together for resource 
sharing, distributed computation, or remote system communication. 


DNA is a layered structure. Modules in each layer perform distinct 
functions. Equivalent modules within the same layer in both the same 
and different nodes communicate uSing- protocols. A node is an 
implementation of the Session Control layer (Section 2.2). Usually a 
Single computer 1S associated with one node. Protocols are the 
messages exchanged by modules and the rules governing the message 
exchanges. Modules in functionally different layers of DNA interface 
uSing either subroutine calls or a system-dependent method. 


A glossary at the end of this document defines many DAP terms. 
Other DNA Phase III functional specifications are: 


DNA Digital Data Communications Message Protocol (DDCMP) 
Functional Specification, Version 4.1.0, Order No. AA-K175A-TK 


DNA Maintenance Operations Protocol (MOP) Functional 
Specification, Version 2.1.0, Order No. AA-K178A-TK 


DNA Network Management Functional Specification, Version 2.0.0, 
Order No. AA-K181A-TK | 


DNA Network Services (NSP) Functional Specification, Version 
3.2.0, Order No. AA-K176A-TK 


DNA Session Control Functional Specification, Version 1.0.90, 
Order No. AA-K182A-TK 


DNA Transport Functional Specification, Version 1.3.@, Order No. 
AA-K18@A-TK 


The following overview document for these specifications iS. an 
introduction to the structure and functions of DNA, 


DNA General Description, Order No. AA-K179A-TK 


2.@ FUNCTIONAL DESCRIPTION 
The Data Access Protocol iS an application level protocol. Its 
primary purpose is to permit remote file access within the DECnet 


environment independently of the I/O structure of the operating Ss 
being accessed. 


2.1 DAP Functions 


Within DECnet, DIGITAL operating satems can employ DAP to provide the 
following remote F- ie access functions: 


@e Retrieve a file from an input device. 

® Store a file on an output device. 

® Provide ASCII file transportability between nodes. 

@ Provide error recovery. 

e Allow multiple data streams to be sent over a logical link. 
e Command file execution Sad: ewemieeion: 

e® Provide for random access of records in a file. 

@ Provide for file deletion. - 

@e Rename files. 


e List directories. 


2.2 Relationship to the DIGITAL Network Architecture 


The DIGITAL Network Architecture provides a modular design for DECnet. 
Its functional components are defined within eight layers which are 
described below. Each layer performs a well-defined set of network 
functions (via network protocols) and presents services to the layer 
above it: | 


User layer. The User layer contains all the user-supplied functions. 
It is the highest layer in the DNA structure. 


Network Management layer. The Network Management layer contains’ the 
modules that provide user control over and access to network 
parameters and counters. Network Management modules also furnish 
down-line loading, up-line dumping, and testing functions. 


Network Application layer. The Application layer supports the various 
user services and programs that utilize the network facilities. These 
services and programs must. utilize the network communication mechanism 
provided by the Session Control and Network Services layers. DAP 
resides within the Application layer. 


Session Control layer. The Session Control layer defines the 
system-dependent aspects of logical link communication. 


Network Services layer. The Network Services layer provides’ the 


mechanism that permits node-to-node communications and 
process-to-process communications between processes in the same or 
different nodes. It provides a logical link service and a datagram 


service to the network. 


Transport layer. The Transport layer provides a mechanism for the 
network service layer to send a unit of data (a packet) from any node 
in the network to any other node in the network. 


Data Link layer. The Data Link layer controls the physical link 
Operation to ensure both data integrity and sequentiality. 


Physical Link layer. The Physical Link layer, the lowest layer, 
consists of device specific modules that provide the interface to the 
communication hardware. 


Figure 1 shows the interrelationship of the DNA layers. 
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Horizontal arrows show direct access for control and examination of parameters, counters, etc. Vertical and 
curved arrows show interfaces between layers for normal user operations such as file access, down-line load, 
up-line dump, end-to-end looping, and logical link usage. 


Figure 1 Interrelationship of DNA Layers 


2.3 Generic Model 


As an aid toward understanding the Data Access Protocol, this section 
contains a generic model. This model consists of a summary of the DAP 
messages (Table 1) and a typical DAP message exchange sequence 
illustrating how DECnet sequential file retrieval is accomplished 
between two dialogue processes (Figure 2). | a 


For a more detailed description of the DAP message formats and the 


protocol operation, refer to Sections 3.@ and 5.@, respectively. 


Table 1 
DAP Messages 


Message Function _ 


Configuration 


Exchanges system capability and 
configuration. information between 
DAP-speaking processes. This message is 
sent immediately after a link is 
established. It contains information about 
the operating system, the file system, 
protocol version, and buffering ability. 


Provides information on how data is 
Structured in the file being accessed. The 
message contains information on file 
Organization, data type, format, record 
attributes, record length, size, and device 
characteristics. 


Attributes 


Access 


Specifies the file name and type of access 
requested. 


Sends control information to a file system 
and to establish data streams. 


Control 


Allows recovery from errors. Used for 
retry, skip, and abort after an error is 
reported. 


Continue-Transfer 


Acknowledge Acknowledges access commands and control 
connect messages used to establish data 


streams. 


Access Complete Controls termination of, file and stream 


access. 


Transfers the file data over the link. 


Data Message 


Status Returns status and information on error 


conditions. 


Key Definition 
Attributes Extension 


Specifies key definitions for indexed 
files. 


Used when creating or explicitly extending 
a file to specify the character of. the 
allocation. 


Allocation | 
Attributes Extension 


(continued on next page) 


Table 1 (Cont.) 
DAP Messages 


Message Function 


Summary Returns Summary information about file. 
Attributes Extension 


Date Time Specifies time-related information about 
Attributes Extension the file. 


Protection Specifies the file protection code. 
Attributes Extension 


Name Sends name information when renaming a file 
or obtaining a directory listing. 


Access Control When creating a file, this message is used 
List Attributes to specify the access rights users are 
Extension granted for access to this file. 


User Node Message | Remote Node Message 
Description — Messages Description 


Configuration Message 
Configuration Information SSS ee 
(e.g., Buffer Size, OS, File 
System DECnet Phase No., 
and DAP Version No.) 
7 Configuration Message 
ee ay Configuration 
Information 
Returned 
Attributes Message 
File Characteristics eS ee ge 
(e.g., Type, BIk Size 
and Record Size) 
Access Message 
Access Request SSS 
Attributes Message 
SS SS Se Actual File Characteristics Returned 
Acknowledge Message 


File Opened 
Control (Initiate Data Stream) 


Message © 
Set up Data Stream 3 


Acknowledge Message 
a Data Stream Established 
Control (Get) Message 
Request Start of Data SS ee 


Transfer and Mode of Record 1 


f 
Transfer —— Data Sent in Records 


. @ 
Record N 
———————— SS 
Status Message | 
—_— End-of-F ile Indicated 


Access Complete Message 
Request to Terminate Se ee ee 


Access Complete Response 
Ee Request Completed Successfully 


Figure 2 Typical DAP Message Exchange (Sequential File Retrieval) 
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3.0 MESSAGE FORMATS 


3.1 Notation 


The following notation is used to describe the DA? messages: 


FIELD (LENGTH) 
where: 
FIELD 


LENGTH 


CODING 


CODING Description of field. 


Is the name of the field being described. 


Is the length of the field, which can be indicated in 
one of four ways: 


1. 
2. 


A number meaning number of 8-bit bytes (octet). 


A number followed by a "B" meaning number of 


bits. 


The letters "EX" meaning extensible field. 
Extensible fields are of variable length 
consisting of 8-bit bytes in which the 
high-order bit of each byte denotes whether the 
next byte is part of the same field. A 1 means 
the next byte is part of this field anda Q 
denotes the last byte. Extensible fields are 
for bit maps only. Seven bits from each octet 
are used aS information bits. The notation 
EX-n means an extensible field where the 
maximum length of the field is n bytes. 


NOTE 
The bit definitions define the 
information bits after removing the 
extension bits = and compressing the 


remaining bits. 


The letters "I-n" means this 1S an image field, 
with n being a number that specifies the 
maximum length of the field in 8-bit bytes. 
The image is preceded by a l-byte count of the 
length of the remainder of the field. Image 
fields are variable in length and may be null 
(count=@). All 8-bits of each byte are used as 
information bits. The meaning and 
interpretation of each image field is as 
defined with that specific field. 


Is the representation type used, where: 


A 
B 
BM 


How tt 


7-bit ASCII 

binary 
bit map (in which each bit has a specific 
meaning). ; 


The following rules apply to the notation: 


1. If length and coding are omitted, field represents a number 
of subfields specified in the description. 


2. Any bit or field described as "reserved" shall be zero unless 
otherwise specified. 


3. All fields are presented to the Session Control Protocol with 
the least-sSignificant byte first. In an ASCII field, the 
left-most character is contained in the low-order byte. 


4. All numbers are in decimal unless otherwise specified. 


5. When default values are defined for fields in DAP messages, 
the values will be used only if that field is absent from the 
message. There are two wayS in which fields within DAP 
messages can be omitted so the default can be used: 


a. A field that appears under a MENU may be omitted by 
setting the corresponding MENU bit to zero. 


b. Trailing fields in DAP messages may be omitted if they 
are not needed or if the default value can be used. If a 
MENU field 1s truncated in this way, its value is zero 
(which means all the fields controlled by the MENU are 
absent, too). 


If a field is present with a zero value, do not use the 
default value. Use the value zero. 


6. Brackets [:] denote optional fields. 


3.2 General Message Format 


All DAP messages have the following form: 


OPERATOR | OPERAND 


where: 


OPERATOR This field describes the characteristics and type of 
message. It is divided into seven subfields: MTYPE, 
FLAGS, STREAMID, LENGTH, LEN256, BITCNT, and SYSPEC. 


TYPE (1) 2. B The type of DAP message. These 
numbers are given with each DAP 
message description. Types 128-191 
are reserved for DIGITAL applications 
based on DAP. Types 192-255 are 
reserved for user extensions to DAP. 


FLAGS (EX-5) : BM. The DAP message flags. Bits in ‘this 
| extensible field are currently 
defined as follows: 


Bit(s) Meaning (When Set) | 


Stream identification field 
present. 


Length field present. 


If bit 1 (length field 
present). is set, field 
LEN256 iS present and the 
length field is in effect 2 
bytes long. ZIllegal if bit 
l not set. | 


The BITCNT field is present. 
Reserved .(@). 
SYSPEC field present. 


If set, this is a segmented 
message and this is not the 
last segment of the message. 
The. next message will 
contain the next segment of 
the full message. The next 
message must be of the same 
type as this message. Refer 
to the SYSCAP field of the 
Configuration message to see 
re this facility is 
Supported. 


STREAMID(1) : B The stream identification field. 
This field is included only if bit @. 
of the FLAGS field is -set. © This 
field is used to allow a single user 
to have multiple data streams in use 
for a single open file. All data 
Streams use the same logical link 
(they multiplex on the STREAMID 
number). » 4 


If the STREAMID number is omitted, it 
is’ assumed to be zero. Not all file 
systems are capable of supporting 
multiple data streams from a single 


file. 

LENGTH(1) : B Denotes the length of the OPERAND 
field (number of 8-bit bytes). This 
field is optional. It is included 


only if bit 1 of the FLAGS field is 
set. Two or more DAP messages may be 
blocked together into one Session 
Control buffer (usually for reasons 
of efficiency). If DAP messages are 
blocked, the LENGTH field must _ be 
present so the end of one message and 
Start of the next can be found. 


LEN256(1) : B 


BITCNT(1) : B 


SYSPEC (I-255) 


B 


Messages between @ and 255 bytes long 
may be blocked using only the LENGTH 
field. DAP messages whose operand 
length is between 256 and 64K bytes 
may be blocked only if both bits 1 
and 2 of FLAGS are set. Lengths 
greater than 64K bytes are sent 
unblocked or as the last part of a 
blocked message. 


Contains the most Significant byte of 
a two byte OPERAND length if bit 2 of 
FLAGS is set. LENGTH contains’ the 
least significant byte. If LEN256 is 
present, LENGTH must also be present. 


This field is valid only with the 
Data message. If present, it 
contains a number in the range Q@-7 
which is the number of unused bits in 
the final 8-bit byte of the message. 
It is required only when transmitting 
data which does not completely fill 
the final 8-bit frame of a Data 
message. This is useful when 
accessing files whose byte size is 
not a multiple of eight. See Section 
4.4.3. 


This optional field is the system 
specific field. It can only be used 
for file access between two 
homogeneous systems. This field is 
included only if bit 5 of the FLAGS 
field is set. If it is used between 
hetrogeneous systems, it will produce 
a fatal error and the access will be 
aborted. Between homogeneous 
systems, this field can be used for 
passing system specific information 
as defined by the system. The SYSPEC 
field can not be used with the 
Configuration message. This field 
must not be used for passing 
information common to more than one 
system. 


NOTE 


If this field is used, all 
system specific functions 
must be registered with the 
architecture group within 
DECnet in advance of 
certification. 


OPERAND 


The information field for DAP messages. 
on the TYPE field. 


NOTE 


Typically, one  DAP-speaking = process 
sends one or more DAP messages to a 
cooperating process which then’ responds 
with one or more messages. Section 5 
contains examples of message sequences. 
This pattern repeats until the access is 
complete. , 


Blocking DAP messages. DAP messages can 
be blocked in one of two ways: 


It is dependent 


1.. The first process blocks and sends. 


DAP messages up to the point where 
it expects a response from the 
cooperating process. It then waits 
for the response. 


2. The first process blocks and_ sends 
DAP messages without regard for 
response from the cooperating 
process. The first process may be 
way ahead of the cooperating 
process. This means the cooperating 


process must be able to receive a 


buffer full of DAP messages, process 
some of them, send a response and 
then continue processing DAP 
messages from the same buffer from 
where it left off before sending the 
response. If the response was an 
error, the unprocessed messages in 
the buffer may no longer be valid 
and must be discarded. : 


The first method of blocking is’ the 


more commonly used. The type of 
blocking a system supports is 
specified in the Configuration 


message. Some small systems may not 
Support blocking at all. 


Truncating DAP messages. DAP messages 
can be truncated up to the point of 
leaving only the TYPE field provided the 
fields truncated are not needed or can 
be defaulted. This is particularly 
useful with the Acknowledge message 
which reduces the ACK to a one _ byte 
message. 


LO 


3.3 Configuration Message 


The Configuration message passes system configuration information 
between the cooperating processes involved in DAP remote file access. 
This message is sent immediately following link establishment. The 
accessed process may wait to receive a Configuration message from the 
accessing process before it sends a Configuration message itself. 
However, this iS not necessary. The Configuration message should not 
be sent blocked with any other DAP message. The reason for this is 
that buffers of the appropriate size can be allocated for receiving 
subsequent DAP messages. The Configuration message format is: 


where: 
CONFIG : The OPERATOR field with TYPE = 1. 


BUFSIZ(2) : B The maximum buffer size (in bytes) of the sending 
system for message exchange. The two cooperating 
DAP speaking processes will use the lesser of the 
two buffer sizes as the maximum size. If one of 
the two systems has an unlimited buffer size, it 
sends a @® and the two systems will use the 
nonzero buffer size as the maximum. if both 
systems send 9@, there is no limit on the length 
of messages sent. 

OSTYPE(1) : B Operating system type (the sending system). 
Values in the range 1-191 are reserved for 
DIGITAL use; 192-255 are reserved for 
user-specified operating systems. | 


Illegal 
RT-11 > 
RSTS/E 
RSX-11S 
RSX-11M 
RSX-11D 
IAS 
VAX/VMS 
TOPS-2@ 
TOPS-198 
RTS-8 
OS-8 
RSX-1L1IM+ 
COPOS/11 (TOPS-28 front-end) 


Q 
1 
2 
3 
4 
5 
6 
7 
8 
9 
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FILESYS(1) : B File system type (of the file system being used 

by the process sending this message). Values in 

—. the range. 1-191 are reserved for DIGITAL . use; 

192-255 are reserved for user-specified file 
systems. : , 


Illegal 
RMS-11 
RMS-20 
RMS-32. 
FCS-11 
RT-11l 

No file system supported 
TOPS-290 
TOPS-19 
OS-8 


ODUHUMABRWHEH® 


VERSION : | A field identifying the protocol and _ software 
version numbers. This field is subdivided as 
follows: oo : 


| VERNUM | ECONUM | USRNUM | SOFTVER}| USRSOFT 


where: 


VERNUM(1) : B DAP version number. This is the 
Same as the first digit of the 
' protocol version number. 


ECONUM(1) : B DAP ECO (Modification) number. 

: | | This is the same as the second 
digit of the protocol version 
number. 


USRNUM (1) : B Customer modification level of 
DAP. Set to @ by DIGITAL. 


SOFTVER(1) : B DAP software version number in 
binary. This is the DIGITAL 
release number. If the software 
is completely user written, this 
field should be @. 


USRSOFT(1) : B User software version number in 
- binary. If the user modifies 
DIGITAL software, he should 
~ increment this byte to reflect 
his modification number. Set to 
@ by DIGITAL. 
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SYSCAP(EX-12) : BM Generic system capabilities. These are defined 
as follows: 


Bit Meaning (When Set) 


4) Supports file preallocation. 

1 Supports sequential file organization. 

2 Supports relative file organization. 

3 Intended to support direct file 
Organization (reserved). 

4 Supports Single keyed indexed file 
Organization (reserved). 


5 Supports sequential file transfer. 

6 Supports random access by record number. 

7 Supports random access by Virtual Block 
Number. 

8 Supports random access by Key. 

9 Intended to support random access by user 
generated hash code (reserved). 

10 Supports random access by Record File 
Address (RFA). 

11 Supports multi-keyed indexed file 
organization. 

12 Supports Switching access mode. (See RAC 
field in Section 3.6.) 

13 Supports append to file access. 

14 Supports command file submission and/or 
execution as specified in the Access 
message. 

15 Supports data compression (reserved). 

16 Supports multiple data streams. 

17 Supports status return (reserved). 

18 Supports blocking of DAP messages up to 
response. (See note Section 3.2.) 

19 Supports unrestricted blocking of DAP 
messages. (See note Section 3.2.) 

20 Supports the use of two byte operand 


length in the DAP message header, i.e., 
LENGTH and LEN256. 

21 Supports the file checksum option (See 
ACCOPT field in the Access message and 
also Section 5.5.2). 


22 Supports the Key Definition Extended 
Attributes message. 

23 Supports the Allocation Extended 
Attributes message. 

24 Supports the Summary Extended Attributes 
message. 

25 Supports directory list. 

26 Supports the Date and Time Extended 
Attributes message. 

27 Supports the File Protection Extended 


Attributes message. 
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| Meaning (When Set) | ef 


Supports the Access Control List Extended 
Attributes message (reserved). 

Supports spooling as specified by bit 29 
of the FOP field (see Attributes and 
Access Complete messages). 

Supports command file submission as 
specified by bit 21 of the FOP field. 
Supports file deletion as specified by 
bit 22 of the FOP field. 

Supports the default file specification 
(see Section 3.17) (reserved). 

Supports sequential record access. 
Supports the recovery option for file 
transfer (reserved). 

Supports the use of the BITCNT field in 
the Data message. 

Supports the warning Status message 
(MACCODE = 6). 

Supports the file rename operation. 
Supports wildcard operations (See Section 
52-6 LOY) « 

Supports the Go/No-Go option (See Section 
3.5, ACCOPT field). (reserved) 

Supports the Name message. 

Supports segmented DAP messages (see bit 

6 of FLAGS field). (reserved) 


NOTE 


Bits 5 and 33 differentiate between the 
use of file transfer (see Sections 5.2.1 
and 5.2.2) and record access on 
sequential files (see Section 5.2.3 and 
5.2.4) where file transfer reduces 
overhead by eliminating the need for 
Control messages. 


3.4 Attributes Message 
The Attributes message describes how data is being represented in a 


File being accessed. It is sent as a part of the-initial set up. The 
Attributes message format is as follows: _ 


where: 
ATTRIB : 


ATTMENU (EX-6) 


BM 


NOTES 


Symbolic names, where supplied, 
refer to the corresponding RMS 
names. They are included here _ for 
ease of reference only; they have 
no meaning for DAP. 


Values passed to the accessed 
system's file system may not be used 
literally in some cases. FOr 
example if a value of @ is passed in 
the DEQ field, RMS systems ignore 
the @ and use the local default 
rather than return an error as might 
be expected. The application of 
defaults, as in this example, is a 
function of individual file systems 
and iS in no way related to defaults 
aS specified in DAP. If a field is 
present in a DAP message, no DAP 
specified default will be 
Substituted in place of the value it 
contains. 


Sometimes fields will be ignored if 
they are not applicable to. the 


particular operation or are not 
Supported and their omission will 
not affect the operation. For 


example, RMS ignores MRS as input to 
the OPEN operation. Also, with bit 
map fields, sometimes bits will be 
ignored where they are not 
applicable to the operation or not 
Supported by that particular file 
system. 


The OPERATOR field with TYPE = 


The following bit map specifies which of 
attributes fields will be present in the main 
attributes message when the corresponding bit 
is set. These fields and only these fields 
may appear in the message and they must be in 


the order specified. 
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DATATYPE (EX-2) 


BM 


Bit Meaning (When Set) 


DATATYPE 

ORG 

RFM 

RAT 

BLS 

MRS 

ALQ 

BKS 

FSZ 

MRN 

RUNSYS 

DEQ 

FOP 

BSZ 

DEV 

SDC (reserved) 
LRL 

HBK 

EBK 

FFB 
SBN 


WOMAN M SP WHF & 


The type of data being transferred. The 
default is Image. Unless a file has 
attributes specifying whether the Pade 
contains ASCII or Image data, the accessed 
process returns the value (ASCII or Image) 
sent by the accessing process when opening a 
Lilie: 


Bit Meaning (When Set) 


ASCII (see Note l). 

Image (default) (see Note 2). 
EBCDIC (reserved). 

Compressed format. 

Executable code. 

Privileged code. | 
Reserved (set ) when sending 
Attributes message; ignore when 
receiving Attributes message). 
Sensitive data -- zero on delete. 
Data in file is set to zero when the 
file is deleted for data security. 


NOTES 


This is the 7-bit ASCII code set as 
defined in the 1968 ANSI Standard. 
When transmitting or receiving 7-bit 
ASCII in 8-bit frames, the _ high 
order bit iS ignored except when 
uSing 7-bit compression. 


Image is the mode where no code-set 


is specified. It is a format for 
sending 8-bit quantities in DAP 
without specifying any code 


representation. The actual data may 


be ASCII, binary or anything else. 
The user process determines how to 
use the data. See Section 4.4.3. 
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ORG(1) : B Attributes of the file being accessed. These 
attributes are as follows: 


Value 7 | 
(octal) Meaning 


FBSSEQ; Sequential (default). 
FBSREL; Relative. 
FBSIDX; Indexed. 
FBSHSH:; Hashed (reserved). 


RFM(1) : B Format of the records being transferred. 
These formats are as follows: 


FBSUDF;:; Undefined record 


format. 

FBSFIX; Fixed-length records 
(default). 

FBSVAR; Variable-length 
records. 


FBSVFC; Variable with fixed 
control format. 
FBSSTM:; ASCII Stream Format. 


RAT (EX-3) : BM Information about the attributes of 
individual records. The default is all bits 
set @. 

Bit Meaning (When Set) | 
Q FBSFTN; Records contain FORTRAN 
carriage control (see Note l). 
J FBSCR; Records have an implied LF/CR 
envelope. | 
2 | FBSPRN; Print file carriage control 


where pre- and post-fix carriage 
control information is stored in the 


fixed header field of files in 
variable with fixed control (VFC) 
format. 

3 FBSBLK; Records that do not’ span 
blocks (see Note 2). 

4 Records have embedded format control 
(see Note 3). 

5 Intended for COBOL carriage control 


(reserved). 
FBSLSA; Line-Sequenced ASCII Format. 
MACY11 format (note 4). 


~] OV 


i? 


MRS (2) 
ALO(I=5) 
BKS(1) : 


NOTES 


FORTRAN Carriage Control. For line 


‘printers and some terminals, treat 


the first character of. each record 
aS a Carriage control character. 


This bit, when set, informs’ the 
system that the record length should 
not exceed the physical device 
blocking size. With -some systems 
and on some I/O devices (for 
example, disk and magnetic’ tape) 
this may be a factor in determining 
the actual format used on the 
device. 


This bit, when set, informs the 


system that records in the file may 
contain format control characters 


(LF, VT, and.so on). 


MACY11 format is a standard used on 
19°s and 20@°s to store files 
destined for PDP-ll’s. These files 
usually contain 8-bit data such as 
object code output by a cross 
compiler. 


Physical block size in bytes on media. 


default value is 512. The actual byte size 


is as specified by field BSZ. 


The length of each file record in number 


bytes. For variable-length records, 
field specifies the maximum record 


When the accessed process receives the MRS 
(maximum record size), it must check 


against the length of its buffer. 


buffer will not accommodate this size record, 
the accessed process should return an error. 
A zero value means no checking is’ performed 
on record size. MRS is used by the various 
file systems in a system-dependent manner. 


The default is @. 


This field specifies the allocation quantity 
in blocks. . For file creation, it specifies 
the initial size of the new file. The actual 
size of the new file is returned in this 


field. The default is @. 


NOTE 


Ignore this value on opening existing 
files. Use this field only to return 
the file size. 


Bucket size in blocks. Used for access to 
relative (not RMS-20), hashed and indexed 
files with RMS. The default is @ (see Note 2 
at the top of Section 3.4). 
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FSZ(1) : B 


MRN(I-5) : B 


RUNSYS (I-40) 


DEQ(2) : B 


FOP (EX-6) 


BM 


A 


Size in bytes of fixed part of variable 


length record with fixed control format. The 
default is ®@ (see Note 2 at the top of 
Section 3.4). 


Maximum record number for file (for relative 
files only). If set to @, checking is 
Suppressed. The default is @. 


Name of the Run-Time System environment 
required to execute the code contained in the 
file. This field is useful to operating 
systems that can emulate other operating 
system environments. The default value is 
accessed-operating-system-dependent. 


File .extension quantum size in virtual 
blocks. This size is the amount of Space, in 
blocks, added to the file each time the file 
is implicitly extended. The default is @ 
(see Note 2 at the top of Section 3.4). 


The file access options a user requires. The 
default is all bits set to @Q. 


Meaning (When Set) 


FBSRWO; Rewind on open. 

FBSRWC:; Rewind on close. 

Reserved (Q@). 

FBSPOS; Position magnetic tape just 
past the most recently 
created file. 

4 FBSDLK; Do not lock file if not 

properly closed. 

2 Reserved (@). 

6 File Locked.» 

7 FBSCTG; A contiguous file creation 
or extension required. 


8 FBSSUP; Supersede existing file on 
create. 
9 FBSNEF; Do not position to EOF on 
opening magnetic tape file 
3 for PUT. 
10 FBSTMP; Create temporary file. 
1l FBSMKD; Create temporary file and 
mark for delete on close. 
12 Reserved (@). 
L3 FBSDMO; Rewind and dismount 
| magnetic tape on close. 
i414 FBSWCK; Enable Write checking. 
15  FBSRCK; Enable Read checking. 
16 FBSCIF; Create new file iff one by 


the same name does not 
exist. If one does exist, 
open the highest version 
of the file. 


17 FBSLKO; Override file lock on open 
(reserved). 

18 FBSSQO; Sequential access only. 

19 FBSMXV; Maximize version number. 


20 FBSSPL; Spool file to line printer 
- (one copy only) on close. 
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Meaning (When Set) 


FBSSCF; Submit as command file on 
ss gdlose. 
FBSDLT; Delete file on close. May 
| be used aS a sSub-option with 
submit or spool. 
FBSCBT; Contiguous best try. The 
file will be created but 
it will be contiguous 
only when it is possible. 
 FBSWAT: Wait for file if it is 
locked by another process 
(reserved). 
FBSDFW; Deferred write (REL and IDX 
files). 
FBSTEF;: Truncate at EOF on close 
(write accessed SEQ files). 
FBSOFP; Output file parse (the name 
type will be preserved 
until overridden). 


BSZ(1) : B- Number of bits per byte for data stored in 
| the file on the accessed node. Data is 
always transmitted in 68-bit frames (see 


Section 4.4). 


When a DAP Attributes message is sent from 
the accessing to the accessed system, BSZ is 
required only when dealing with systems 
capable of supporting a variable byte size, 
such as TOPS-2@. The default value for BSZ 
is the normal default for the accessed 
system’s file system, for example, 8 bits per 
byte for RSX. 


When the Attributes message is returned from 
the accessed to the accessing system, BSZ 
should always be sent unless the default 
applies. The default for BSZ in a returned 
Attributes message is 8 bits. 


DEV(EX-6) : BM | For attributes sent to the accessing node, 
this field contains the generic 
characteristics of the device on which a file 
resides. The default is all bits set to Q. 


Bit Meaning (When Set) 


FBSREC; Record oriented. 

FBSCCL; Carriage control device. 
FBSTRM; Terminal. 

FBSMDI; Directory structured. 

FBSSDI; Single directory only. 

FBSSQD; Sequential, block oriented (for 


example, magnetic tape). 
* Null device. 

FBSFOD; A file-oriented device (for 
example, a disk or magnetic 
tape). 

* Device can be shared. 

FBSSPL; Device is being spooled. 

FBSMNT; Device is currently mounted. 

FBSDMT; Device is marked for dismount. 
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Meaning (When Set) 


FBSALL; Device is allocated. 
FBSIDV; Device is capable of providing. 


input. 

FBSODV; Device is capable of providing 
output. 

FBSSWL: Device is software write- 
locked. | 


FBSAVL; Device is available for use. 
FBSELG; Device has error logging 
enabled. 
FBSMBX; Device 1S a mailbox. 
FBSRTM; Device is realtime in nature, 
not Suitable for RMS uSe. 
FBSRAD; A random access device. 
* Device has read checking 
enabled. 
> Device has write checking 
enabled. 
; Device is foreign. 
» Network device. 
¢ Generic device. 


SDC(EX-6) : BM Spooling device characteristics. SDC uses 
(Reserved for the same bit definitions as in the DEV field. 
future use) If the file is spooled, SDC contains’ the 


characteristics of the spooling device. The 
characteristics of the ultimate device are 


contained in DEV. The default is all bits 
set to @. 

LRL(2) : B Longest record length. Length of the longest 
record in the file. 

HBK(I-5) : B Highest virtual block allocated to the file. 

EBK(I-5) : B End of file virtual block number. 

FFB(2) : B First free byte in end of file block--byte 


size as defined in BSZ. 


SBN(I-5) : B Starting logical block number for file if 
contiguous; else @Q. 


3.5 Access Message 


The Access message specifies the file name and type of access 
requested. The format for the Access message is as follows: 


ACCESS |ACCFUNC |ACCOPT | FILESPEC DISPLAY| PASSWORD 


NOTE 


Symbolic names, where supplied, refer to 
the corresponding RMS names. They are 
included here for ease of reference 
only. They have no meaning for DAP. 
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where: | 
ACCESS : The OPERATOR field with TYPE = 3. 


ACCFUNC(1) : B ‘The request code specifying the operation to be 
performed is as follows: 


SOPEN; Open existing file. 
SCREATE; Open new file. 

SRENAME; Rename a file. 

SERASE; Delete a file. 

Reserved. 

Directory List. | | 

Submit as a command (batch) file. 
Execute command (batch) file. 


ONIN Se WN FE 


If SRENAME is specified, the FILESPEC field below 
contains the old file specification and the new 
file specification is contained in the Name 
message which follows the Access message. 


If SCREATE iS specified, but a file of that name 
already exists, follow the rules of the accessed 
node for file creation. .For example, the file 
system may create a new file whose version number 
is one greater than the current highest version 
number. 


NOTE 


The Data Access Protocol (DAP) does not 
perform functions beyond remote data 
access. DAP should not be extended to 
include RJE, spooling, or other similar 
functions which, while they involve file 
transfer, also require command processing, 


parameter passing, and job queueing. The 
two command file submission commands are 
here for historical reasons: they were 


implemented in the first release of 
DAP-based software. | 


ACCOPT(EX-5) : BM The access options are as follows: 


Bit Meaning (When Set) | | 


I/O errors are non-fatal. A record may be 
skipped or repeated as specified by the 
Continue Transfer message. If not set, 
I/O errors are fatal and terminate the 


access.. 


A status message will be returned 
following each record sent to the accessed 
process in the record access mode 
(reserved). 
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Bit Meaning (When Set) 


2 A status message iS returned with each 
record retrieved from an accessed system. 
The status message should precede the Data 
message so that it is always possible to 
block the two into one Session Control 
buffer. When a user requires a Record 
File Address (RFA) to be returned, this 
option is used (reserved). 


3 A 16 bit file checksum will be generated 
by both the transmitting and receiving 
nodes. When closing the file, the 


accesSing process sends’ the checksum it 
generated to the accessed process in the 
Access Complete (Close) message. The 
accessed process closes the file if the 
checksums agree. If they do not agree, it 


returns a status message. See Section 
Dees 

4 The Go/No-Go option is to be used with 
this operation. Go/No-Go is valid only 
for the Delete, Rename, and Execute 
Command File functions and wildcard 
operations using these functions. 


Go/No-Go operation causes the accessed 
process to return the name of the file to 
the accessing process before executing the 
operation. The accessing process can then 
choose whether or not to perform the 
operation on the file by sending either a 
Control (Resume) Or Control (Skip) See 
Section 5.2.11 for state operation. 


FILESPEC The file specification in the format required by 

(I-255) : A the remote node. A null file specification 
assumes the meaning of a null file specification 
on the target node. 


FAC(EX-3) : BM The file access operations a user requires: 


Bit Meaning (When Set) 


FBSPUT; Put access. 
FBSGET; Get access (default). 
FBSDEL; Delete access. 


FBSUPD; Update access. 

FBSTRN; Truncate access. 

FBSBIO; Block I/O acess (See Note). 

FBSBRO; Support switching between 
block and record I/O. 


NOTE 


FBSREA = FBSBIO!FBSGET: Block I/O Read access. 
FBSWRT = FBSBIO!FBSPUT; Block I/O Write access. 
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SHR(EX-3) : BM © Operations shared with other users: 


Meaning (When Set) 


FBSPUT; Put access. 

FBSGET; Get access (default). 
FBSDEL: Delete access. 
FBSUPD; Update access. 
FBSMSE; Enable multi-Sstream access. 
FBSUPI; User provided interlocking 
(allows multiple writers to SEQ 
files). 

No access by other users. 


FBSNIL: 


DISPLAY(EX-4): BM Attributes and Extended Attributes messages which 
| are to be returned in response to this Access 
message. See note 2 Section 3.6. 


Bit Meaning (When Set) 


Main Attributes message (see Note 
Section 5.1.2). 

Key definition Attributes message. 
Allocation Attributes message. 
Summary Attributes message. 

Date and Time Attributes message. 
File Protection Attributes message. 
Reserved (@). 

Access Control List 

Attributes message (reserved). 

Name message containing resultant 
file specification. If the file 

was opened uSing logical name(s), 
this will return the file specification 
of file opened without logical names. 


NOTE 


When opening a file and DISPLAY 
requests key definition and 
allocation attributes for that 
file, the Attributes message must 
be followed by Key Definition and 
Allocation Attributes Extension 
messages specifiying for which 
keys and which areas this 
information is to be returned. If 
no keys or areaS are specified, no 
key or area information will be 
returned. See Section 5.1.2 for 
the setup message sequence. 


PASSWORD (I-40): B Password required to obtain access to file. 
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3.6 Control Message 


The Control message sends control type information to a file system. 
The Control message format is as follows: 


[cowmRot] Crcronc | emcwan] RAC] Key] Kae [ROP [Asa] DISPLAY 


where: 
CONTROL : The OPERATOR field with TYPE = 4. 
CTLFUNC(1) : B Specific control information: 
1 -SGET (or SREAD for block I/O); Get record 
(Or block). If random access to a 


relative file is made, the KEY field 
contains the record number. If a random 
access to an indexed file is made, KEY 
contains the key. If sequential access is 
employed, get the next record (default). 


2 SCONNECT; Initiate data stream. If 
multiple data streams are used, they are 
multiplexed on the STREAMID number. The 


STREAMID number in the Control message 
initiates a data stream. If the STREAMID 
number iS omitted, assume a default of 
zero. 


3 SUPDATE: Update current record. 
Indicates to the accessed system the 
intent of the accessing system to update 
the currently positioned record with the 
next data transmission. 


4 SPUT (or SWRITE for block I/O); Indicates 
to the accessed system, that the 
information to follow should be written 
into the file. 


5 SDELETE: Delete current record. 

6 SREWIND;: Rewind file. 

7 STRUNCATE ; Truncate file. Writes 
end-of-file at current position. Used 


with sequential files only. 


8 SMODIFY; Change file attributes 
(reserved). 


9 SRELEASE; Unlock record specified by 
Record File Address in KEY field 
(reserved). 


10 SFREE; Unlock all locked records for this 
data stream. 


11 Reserved. 
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SFLUSH; Write out all modified 1/0 
buffers and attributes for this data 
stream.. 


SNXTVOL; Perform end-of-volume and 
start-of-next-volume _ processing 
(reserved). 


SFIND; Find record. Same as 1, but the 
data is not transferred. 


SEXTEND; Extend this file by the amount 
specified in the following Allocation 
Attributes Extension message (reserved). 


SDISPLAY; Retrieve this file’s attributes 
as defined by the field DISPLAY 
(reserved). 


SPACE FORWARD; Forward space the file by 
the number of blocks specified by KEY 
below. Block I/O only. | 


SPACE BACKWARD; Backward space the file 
by the number of blocks specified by KEY 
below. Block I/O only. 


CTLMENU (EX-4) :BM The following bits when set, indicate the 
following optional fields are present. These 
fields and only these fields may appear in the 
message and they must be in the order specified. 


RAC 


KEY 

KRF 

ROP 

HSH (reserved) 
DISPLAY (reserved) 


RAC(1) : B Sets the access mode. If this field is not 
present, retain the option in force for the last 
access. The default is @ if not set previously. 


RBSSEQ; Sequential record access. 

RBSKEY; Keyed access. 

RBSRFA; Access by Record File Address 
(RFA--an RMS specific access mode). 
Sequential file access (the remainder of 
the file is transferred sequentially from 
the current file position). 

Block mode; Access by Virtual Block 
Number. For retrieval, a Control message 
must request each block as in the record 
access mode. 

Block mode file transfer. Blocks are 
transferred sequentially to end-of-file 
without need for a Control message 
preceding each block transferred. An 
explicit Control (Get) Or (Put) is 
required to start data moving. 


KEY (I-255) 


KRF(1) : B 


ROP (EX-6) 


HSH(I-5) : 


B 


BM 


(Reserved for 


future use) 


g 
1-254 


File or Mode 


Record Number 
Record Key 
Record Key 


Relative Files 
Indexed Files 
Hashed Files 

Record File Address 
Access Mode 

Block Mode Access 


Record File Address 
Virtual Block Number 
(binary, range 1 to n) 
Input File Checkpoint 
Locater 


Recovery 


Right justify non 8-bit quantities in the KEY 
field with the high order and unused bits set to 
Zero. If the key consists of 7-bit ASCII 
characters, right justify each 7-bit character in 
an 8-bit frame as is usual for the transmission of 
ASCII characters. 


If this field is not present, 
Default is 


Key of reference. 
do not change the key of reference. 
primary if never set. 


Primary key 
Secondary key indicator 


Optional record processing features. If this 
field is not present, retain the options in force 
for the last access. 


Meaning (When Set) 


RBSEOF; Position to EOF. 

RBSFDL; Fast delete--mark record 
deleted but do not remove 
pointers from index. 


RBSUIF; 
RBSHSH; 


RBSLOA; 
RBSULK; 


RBSTPT; 


RBSRAH; 
RBSWBH; 
RBSKGE; 
RBSKGT; 
RBSNLK; 
RBSRLK;: 


RBSBIO; 
RBSLIM; 


RBSNXR; 


code if 
employed and the user is doing hashing. 


SPUT’s update existing 
records in relative files. 
Use hash code in HSH 


(reserved). 


Follow fill quantities. 
Manual locking/unlocking 
(reserved). 

Truncate Put--writes EOF 
at current position. SEQ files 
only (Put also occurs). 
Read ahead. 

Write behind. 

Key iS >=. 

Key is >. 

Do not lock record. 

Read a locked record (read 
only). 

Block I/O. 

Compare for key limit 
reached (reserved). 
Non-existent record 
processing (reserved). 


keyed access on direct file 
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is 


DISPLAY (EX~-4) 
(Reserved for 
future use) 


BM 


Attributes messages to be returned in response 
to a request to retrieve the file’s attributes 


are: 


Main Attributes message. 
Key definition attributes. 
Allocation attributes. 

Summary Attributes message. 

Date and Time Attributes message. 


Reserved (@). 
Access Control List Attributes 
(reserved). | 


SID OT BP WD EF ® 


mee) 


specification--if file opened 
logical name(s), this returns 


logical names. 


NOTE 


When a file’s attributes and Key 
definition and/or allocation 
attributes have been requested in 
the DISPLAY field of a Control 
message, the Control message must 
have been preceded by Key Definition 
and/or Allocation Attributes 
Extension messages specifying for 
which Keys and/or areas this 
information is to be returned. If 
no keys or areas are specified, no 
Key or area information will be 
returned. See Section 5.2.18 for 
the message sequence. 


An accessing process’ seeing the 
accessed process does not support a 
particular message type (as 
indicated in the Configuration 
message from the accessed process) 
does not request that message type 
in the DISPLAY field of either the 
Access Complete or Control messages. 
If an unsupported message type is 
requested, return an error. 


FAL’S written to versions of DAP 
prior to 5.6 will not return a 
Status message for successful 
completion with Get, Put, Delete, 
and Find operations. FAL’s' written 
to DAP version 5.6 and later 
versions will return successful 
status for these operations. See 
Sections 5.2.3, 5.2.4, 5.2.17 and 
5.2.18 for the operation of these 
functions. 
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Meaning (When Set) | 


File Protection Attributes message. 


Name message containing resultant 


specification of the file opened without 


3.7 Continue Transfer Message 


The Continue Transfer message tells the accessed process what action 
to take when an error is detected in an I/O transfer. Normally, the 
accessed process informs the accessing process of an I/O error uSing a 
Status message. The accesSing process returns a Continue Transfer 
message. This message iS also used when the accessed process suspends 
to await an operator decision as with Go/No-Go operation. The format 
of the Continue Transfer message is: 


CONTRAN | CONFUNC 
where: 
CONTRAN : The OPERATOR field with TYPE = 5. 


CONFUNC(1) : B This field specifies the recovery action to be taken: 


Try again. 
Skip and continue. 
Abort transfer. (Discard all records in the 


pipeline until an Access Complete message is 
found indicating the pipeline is clear.) 
Resume processing (used to restart accessed 
process procesSing data for this data stream 
if the accessed process is Suspended). 


3.8 Acknowledge Message 


The Acknowledge message acknowledges access commands, control 
connects, and the taking of a checkpoint. Its format is as follows: 


ACKNOWLEDGE 


where: 


ACKNOWLEDGE: The OPERATOR field with TYPE = 6. 


3.9 Access Complete Message 
The Access Complete message either terminates access or acknowledges a 


request to terminate access. The Access Complete message format is as 
follows: 


where: 


ACCOMP : The OPERATOR field with TYPE = 7. 
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CMPFUNC(1) : B The access completion functions are: 


Close. Terminate access. Close a file that 
is currently open. When multiple data 
streams are in use, close all of them 
(SCLOSE). | 


Response. Sent by the accessed process in 
response to all Access Complete messages from 
the accessing process unless an error occurs. 


Purge. Purge a file. That is, close and 
delete (SCLOSE + SERASE) the file. 


End-of-—stream. Terminate the data stream 
associated with this STREAMID number, but do 
not close the file (SDISCONNECT). 


Skip. Close the file currently associated 
with this link (forcefully, if 
necessSary-~ignore any errors that may occur 
in closing the file) and go on to process the 
next file. This function is for use with a 
series of wildcard transfers. 


NOTE 


FAL’s written to DAP version 4.1 
will not return an Access Complete 
(Response) to an Access Complete 
(End-of-Stream) (EOS). FAL ‘s 
written to later versions of DAP 
will return an Access’ Complete 
(Response). The Access Complete 
(End-of-Stream) does not close the 
file. The accessed process should 
be in a state wherein it can 
accept another Control (Connect) 
to open another stream. 


FOP(EX-6) : BM The file access options a user requires. Refer to 
Section 3.4 for option values. If any portion of the 
FOP field in the Access Complete is present, the 
whole FOP from the Attributes is superseded with 
unspecified bits being set @Q@. 


CHECK(2) : B The 16 bit file checksum if requested in the ACCOPT 
field of the Access message. See Section 5.5.2. 
Send the checksum only in the Access Complete (Close) 
message. Return a Status message if the checksum is 
incorrect. When this field is present, the accessed 
process compares the checksums. If this field is 
absent, make no checksum comparison and close the 
file even if it is known to contain errors. 


30 


3.18 Data Message 


The Data message transfers the file data over a DAP link. The Data 
message format is as follows: : 


DATA | RECNUM | FILEDATA 


where: 
DATA 3 The OPERATOR field with TYPE = 8. 


RECNUM(I-8) : B This field sends the record number when accessing 
relative files (or sequential files in a relative 
manner, in other words, by record number). For 
random store, this field contains the record number 
(for relative files) or hash code (if the user is 
generating his own hash codes with hashed files). 
When RECNUM is not used, the byte count iS zero. 
When in block mode, this field contains the VBN 
instead of the record number. For file retrieval 
with recovery, this field contains the input file 
checkpoint locater. 


FILEDATA The file data being transferred. This field is 
totally transparent and uses all 8-bits of each 
byte. 


3.11 Status Message 


The status message returns information on the status of DAP messages 
or data transfers. This message is sent synchronously in response to 
another DAP message or an error during data transfer. The format is: 


STATUS | STSCODE RECNUM 


where: 
STATUS The OPERATOR field with TYPE = 9. 
STSCODE A 2-byte status field (16 bits) subdivided as: 
15 2 * 8 
where: 
MACCODE(4B):B The macro. or functional group 
reason for the Status message. 
Table 2 specifies values for this 
field. 
MICCODE(12B):B The specific type of status (by 
MACCODE type). Tables 3, 4, and 5 
specify values for this field. 
RFA(I-8) : B Returns the Record File Address of the record to 


which this Status message applies. If the Access 
message field ACCOPT indicates a return of status 
after each record is stored, then this’ field 
contains the record file address of the record in 
the accessed system's file. 


RECNUM (I-8) 


STV(I-8) : 


Value 
(Octal) E 


12 


al 


12 


13-15 
“16-17 


B 


Returns the record number for relative files when a 


Pending 


Successful 


Unsupported 


Status message 1S returned after each record is 
transferred (aS specified in the ACCOPT field of the 
Access message). The RECNUM field is null for 
non-relative files. 
Secondary status. Used to return secondary status 
information where required. (For example, RMS uses 
it for device error codes.) 
-. Table 2 | 
MACCODE Field Values 
Meaning 
| Operation in progress. 
Returns information that indicates 
success. | 
This implementation of DAP does not 
support the specified request. For 
example, this is used when an 
unsupported bit/field or a field/value 
is encountered which a particular 


File Open 


Transfer 
Error 


Transfer 
Warning 


Access 
Termination 


Format 


Invalid 


Field 


implementation does not support. 
Reserved. 


Errors that occur before a file is 
successfully opened. 


Errors that occur after opening a file 
and before closing that file. | 


For operations on open files, indicates 
the operation completed but not with 


complete success. 


Errors associated with 


access to a file. 


terminating 


Error in parsing a message. Format is 


not correct. 


of message is invalid (for 
example, bits that are meant to be 
mutually exclusive are set, an undefined 


bit is set, a field value is out of 
range or an illegal string is in a 
field). 7 | 
DAP message received out of 


synchronization. 
Reserved. | 


User defined STATUS MACCODES 


Table 3 
MICCODE Field Values for Use with MACCODE 
Values of 2, 10, and 11 Octal 


Code 
Type of Error (Octal) Reason 


NOTE 


MICCODE Format: Bits @-5 specify the 


DAP message field number. Bits 6-11 
specify the DAP message type number. 


Miscellaneous 20 02 Unspecified DAP message error. 
G2 10 DAP message type field (TYPE) error. 


Configuration G1 88 Unknown field. 
Message 
errors by field G1 10 DAP message flags field (FLAGS). 
@1 11 Data stream identification field 
(STREAMID). 


G1 12 Length field (LENGTH). 
G1 13 Length extension field (LEN256). 
G1 14 BITCNT field (BITCNT). 


G1 20 Buffer size field (BUFSIZ). 

@1 21 Operating system type field (OSTYPE). 

®1 22 File system type field (FILESYS). 

G1 23 DAP version number field (VERNUM). 

G1 24 ECO version number field (ECONUM). 

@1 25 USER protocol version number field 
(USRNUM) . 

@1 26 | DEC’ software release number field 
(SOFTVER). 

@1 27 User software release number field 
(USRSOFT). 

G1 32 System capabilities field (SYSCAP). 


Attributes G2 02 Unknown field. 
Message 
errors by field G2 10 DAP message flags field (FLAGS). 
@2 11 Data stream identification field 
(STREAMID). 


92 12 | Length field (LENGTH). 

@2 13 Length extension field (LEN 256). 
82 14 Bit count field (BITCNT). 

@2 15 System specific field (SYSPEC). 


G2 20 Attributes menu field (ATTMENU). 
@2 21 Data type field (DATATYPE). 

@2 22 File organization field (ORG). 

@2 23 Record format field (RFM). 

G2 24 Record attributes field (RAT). 

@2 25 Block size field (BLS). 

Q@2 26 Maximum record size field (MRS). 
@2 27 Allocation quantity field (ALQ). 
G2 30 Bucket size field (BKS). 

G2 31 Fixed control area size field (FSZ). 
@2 32 Maximum record number field (MRN). 


(continued on next page) 
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Table 3 (Cont.) 
MICCODE Field Values for Use with MACCODE 
Values of 2, 180, and 11 Octal . 


Code 
Type of Error (Octal) Reason 


Attributes Run-time system field (RUNSYS). 
Message Default extension quantity field (DEQ). 
errors by field | File options field (FOP). 
(Cont.). Byte size field (BSZ). 
Device characteristics field (DEV). 
Spooling device characteristics field 
(SDC); (reserved). 
Longest record length field (LRL). 
Highest virtual block allocated field 
(HBK). 
End of file block field (EBK). 
First free byte field (FFB). 
Starting LBN for contiguous file (SBN). 


Access Unknown field. 

Message | | 

errors by field DAP message flags field (FLAGS). 
Data stream identification 
(STREAMID). 
Length field (LENGTH). 
Length extension field (LEN256). 
Bit count field (BITCNT). 

| System specific field (SYSPEC). 


Access function field (ACCFUNC). 
Access options field (ACCOPT). 
File specification field (FILESPEC). 
File access field (FAC). 
File sharing field (SHR). 
Display attributes request field 
(DISPLAY). 
File password field (PASSWORD). 
Control Unknown field. 
Message | | | 
errors by field | DAP message flags field (FLAGS). 
Data stream identification 
(STREAMID). 
Length field (LENGTH). 
Length extension field (LEN256). 
Bit count field (BITCNT). 
System specific field (SYSPEC). 


Control function field (CTLFUNC). 
Control menu field (CTLMENU). 

Record access field (RAC). 

Key field (KEY). 

Key of reference field (KRF).. 

Record options field (ROP). 

Hash code field (HSH); Reserved for 
future use. | 

Display attributes. request field 
(DISPLAY). 


(continued on next page) 
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Table 3 (Cont.) 


MICCODE Field Values for Use with MACCODE 
Values of 2, 1@, and 11 Octal 


Type of Error 


Continue 
Message 
errors by field 


Acknowledge 
Message 
errors by field 


Access Complete 
Message 
errors by field 


Data Message 
errors by field 


Code 
(Octal) 


Reason 


Unknown field. 


DAP message flags field (FLAGS). 
Data stream identification 
(STREAMID). 

Length field (LENGTH). 


Length extension field (LEN256). 


Bit count field (BITCNT). 
System specific field (SYSPEC). 


Continue transfer function 


(CONFUNC) . 


Unknown field. 


DAP message flags field (FLAGS). 
Data stream identification 
(STREAMID). 

Length field (LENGTH). 

Length extension field (LEN256). 
Bit count field (BITCNT). 

System specific field (SYSPEC). 


Unknown field. 


DAP message flags field (FLAGS). 


Data stream identification 

(STREAMID). 

Length field (LENGTH). 

Length extension field (LEN256). 
Bit count field (BITCNT). 

System specific field (SYSPEC). 


Access complete Function 
(CMPFUNC). 

File options field (FOP). 
Checksum field (CHECK). 


Unknown field. 


DAP message flags field (FLAGS). 


Data stream identification 
(STREAMID). 

Length field (LENGTH). 

Length extension field (LEN256). 
Bit count field (BITCNT). 

System specific field (SYSPEC). 


Record number field (RECNUM). 
File data field (FILEDATA). 


(continued on next 
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field 


field 


field 


field 


field 


field 


page) 


Table 3 (Cont.) 
MICCODE Field Values for Use with MACCODE 
Values of 2, 18, and-1l Octal 


Code : 
Type of Error — (Octal) Reason 
Status Message ‘ll oo Unknown field. 


errors by field 
11 10 DAP message flags field (FLAGS). 
11 11 Data stream identification 

(STREAMID). 

11 12 Length field (LENGTH). 
11 13 Length extension field (LEN256). 
11-14 Bit count field (BITCNT). 
Pde LS System specific field (SYSPEC). 


11 2¢ Macro status code field (MACCODE). 
11 21 Micro status code field (MICCODE). 
1.22 Record file address field (RFA). 
ll 23 Record number field (RECNUM). 

ll 24 Secondary status field (STV). 


Key Definition 12 02 Unknown field. 

Message errors | 

by field: 12 10 DAP message flags field (FLAGS). 
, 12 11 | Data stream identification 


(STREAMID). 
12 12 | Length field (LENGTH). 
12 13 Length extension field (LEN256). 
12 14 Bit count field (BITCNT). 
12 15 System specific field (SYSPEC). 


12 20 Key definition menu field (KEYMENU). 
12 21 Key option flags field (FLG). 

12 22 Data bucket fill quantity field (DFL). 
12 23 Index bucket fill quantity field (IFL). 
12 24 | Key segment repeat count field (SEGCNT). 
12 25 Key segment position field (POS). 

12 26 Key segment size field (SIZ). 

12 27 Key of reference field (REF). 

12 3@ | Key name field (KNM). 

12 31 Null key character field (NUL). 

12 32 Index area number field (IAN). 

12 33 Lowest level area number field (LAN). 
12 34 Data level area number field ae 

12 35 Key data type field (DTP). 

12 36 Root VBN for this key field (RVB) . 

12 37 Hash algorithm value field (HAL). 

12 40 First data bucket VBN field (DVB). 

12 41 Data bucket size field (DBS). 

12 42 Index bucket size field (IBS). 

12 43 Level of root bucket field (LVL). 

12 44 Total key size field (TKS). 

12 45 Minimum record size field (MRL). 


(continued on next page) 
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Table 3 (Cont.) 
MICCODE Field Values for Use with MACCODE 
Values of 2, 10, and 11 Octal 


Code 
Type of Error (Octal) Reason 
Allocation 13 08 Unknown field. 
message errors 
by field: 13 19 DAP message flags field (FLAGS). 
13:11 Data stream identification field 
(STREAMID). 
13 12 Length field (LENGTH). 
13.13 Length extension field (LEN256). 
13 14 Bit count field (BITCNT). 
13:.45 System specific field (SYSPEC). 
13 20 Allocation menu field (ALLMENU). 
13° 24. Relative volume number field (VOL). 
bs 22 Alignment options field (ALN). 
13 23 Allocation options field (AOP). 
13 24 Starting location field (LOC). 
13.25 Related file identification field (RFI). 
13 26 Allocation quantity field (ALQ). 
13°27 Area identification field (AID). 
13 30 Bucket size field (BKZ). 
i Re ae a Default extension guantity field (DEQ). 
Summary 14 @@ Unknown field. 
Message - 
errors by field 14 12 DAP message flags field (FLAGS). 
14 ll Data stream identification field 
(STREAMID). 
14 12 Length field (LENGTH). 
14 13 Length extension field (LEN256). 
14 14 Bit count field (BITCNT). 
14 15 System specific field (SYSPEC). 
14 20 Summary menu field (SUMENU). 
14 21 Number of keys field (NOK). 
14 22 Number of areas field (NOA). 
14 23 Number of record descriptors field 
(NOR). 
14 24 Prologue version number (PVN). 
Date and Time 15 @@ Unknown field. 
Message 15 10 DAP message flags field (FLAGS). 
errors by field 15 11 Data stream identification field 


(STREAMID) . 
15 12 Length field (LENGTH). 
15 13 Length extension field (LEN256). 
15 14 Bit count field (BITCNT). 
15 15 System specific field (SYSPEC). 


15 20 Date and time menu field (DATMENU). 

15 21 Creation date and time field (CDT). 

15 22 Last update date and time field (RDT). 
15 23 Deletion date and time field (EDT). 
‘15 24 Revision number field (RVN). 


(continued on next page) 
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Table 3 (Cont.) . 
MICCODE Field Values for Use with MACCODE 
Values of 2, 19, and 11 Octal 


Code 
Type of Error |(Octal) _ Reason | 


Protection Unknown field. | | 
Message DAP message flags field (FLAGS). 
errors by field Data stream identification 
— (STREAMID). 
Length field (LENGTH). 
Length extension field (LEN256). 
Bit count field (BITCNT). 
System specific field (SYSPEC). 


Protection menu field (PROTMENU). 

File owner field (OWNER). 

System protection field (PROTSYS). 
Owner protection field (PROTOWN) . 

Group protection field (PROTGRP). 

World protection field (PROTWLD). 


Name Message Unknown field. 


errors by field | DAP message flags field (FLAGS). 
| Data stream identification 
(STREAMID). 
Length field (LENGTH). 
Length extension field (LEN256). 
Bit count field (BITCNT). 
System specific field (SYSPEC). 


Name type field (NAMETYPE). 
Name field (NAMESPEC). 


Access Control 7 Unknown field. 
List Message > | | 
errors by field: DAP message flags field (FLAGS). 
(Reserved for Data stream identification 
future use) | (STREAMID). : 
| Length field (LENGTH). 
Length extension field (LEN256). 
Bit count field (BITCNT). 
System specific field (SYSPEC). 


Access control list repeat count field 
(ACLCNT) . | 
Access control list entry field (ACL). 
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Table 4 
MICCODE Field Values for Use with MACCODE 
Values of @, 1, 4, 5, 6, and 7 Octal 


Value Error/Reason 
(Octal) 


NOTE 


MICCODE Format: Bits @-ll contain the error code 


number. Symbolic status codes, where supplied, 
refer to the corresponding RMS status codes. 
These codes are included here for ease of 
reference only. They have no meaning for DAP. 


Q Unspecified error. 

1 ERSABO; Operation aborted. 

2 ERSACC: F11-ACP could not access file. 

3 ERSACT; FILE activity precludes operation. 

4 ERSAID; Bad area ID. 

5 ERSALN; Alignment options error. 

6 ERSALQ; Allocation guantity too large or @ value. 


7 ERSANI: Not ANSI D format. 
1@ ERSAOP; Allocation options error. 
1] ERSAST; Invalid (1.e., synch) operation at AST level. 
12 ERSATR; Attribute read error. 
13 ERSATW; Attribute write error. 
14 ERSBKS; Bucket size too large. 
LS ERSBKZ; Bucket size too large. 
16 ERSBLN; BLN length error. 
17 ERSBOF; Beginning of file detected. 
20 ERSBPA; Private pool address. 
21 ERSBPS; Private pool size. 
22 ERSBUG; Internal RMS error condition detected. 
23 ERSCCR; Cannot connect RAB. 
24 ERSCHG; SUPDATE changed a key without having attribute of 
XBSCHG set. 
25 ERSCHK; Bucket format check-byte failure. 
26 ERSCLS; RSTS/E close function failed. 
27 ERSCOD; Invalid or unSupported COD field. 
30 ERSCRE; F11-ACP could not create file (STV=sys err code). 
31 ERSCUR; No current record (operation not preceded by 
GET/FIND). 
32 ERSDAC; F11-ACP deaccess error during CLOSE. 
33 ERSDAN; Data AREA number invalid. 
34 ERSDEL; RFA-Accessed record was deleted. 
35 ERSDEV; Bad device, or inappropriate device type. 
36 ERSDIR; Error in directory name. 
37 ERSDME; Dynamic memory exhausted. 
4Q ERSDNF; Directory not found. 
4l ERSDNR; Device not ready. 
42 ERSDPE; Device .has positioning error. 
43 ERSDTP; DTP field invalid. | 
44 ERSDUP; Duplicate key detected, XBSDUP not set. 
45 ERSENT; RSX-F11ACP enter function failed. 
46 ERSENV; Operation not selected in ORGS macro. 
47 ERSEOF; End-of-file. © © 
50 ERSESS; Expanded string area too short. 
onl ERSEXP; File expiration date not yet reached. 


(continued on next page) 
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Table 4. (Cont.) 
MICCODE Field Values for Use with MACCODE 
Values of @, 1, 4, 5, 6, and 7 Octal 


Value Error/Reason 
(Octal) 


ERSEXT; File extend failure. 

ERSFAB; Not a valid FAB (BID NOT = FBSBID). 

ERSFAC; Illegal FAC for REC-OP,@, or FBSPUT not set for 

| | CREATE. 

ERSFEX; File already exists. 

ERSFID; Invalid file I.D. 

ERSFLG;, Invalid flag-bits combination. 

ERSFLK; File is locked by other user. 

ERSFND; RSX-FI11ACP FIND function failed. 

ERSFNF; File not found. 

ERSFNM; Error in file name. 

ERSFOP; Invalid file options. 

ERSFUL; DEVICE/FILE full. 

ERSIAN; Index AREA number invalid. 

ERSIFI; Invalid IFI value or unopened file. 

ERSIMX; Maximum NUM(254) areas/key XABS exceeded. 

ERSINI; SINIT macro never issued. 

ERSIOP; Operation illegal Or invalid for file 
organization. | 

ERSIRC; Illegal record encountered (with sequential files 
only). 

ERSISI: Invalid ISI value, on unconnected RAB. 

ERSKBF; Bad KEY buffer address (KBF=0). 

ERSKEY; Invalid KEY field (KEY=@/neg). 

ERSKRF; Invalid key-of-reference (SGET/SFIND). 

ERSKSZ; KEY size too large. | 

ERSLAN; Lowest-level-index AREA number invalid. 

ERSLBL; Not ANSI labeled tape... 

ERSLBY; Logical channel busy. 

ERSLCH; Logical channel number too large. 

ERSLEX; Logical extend error, prior extend still valid. 

ERSLOC; LOC field invalid. 

ERSMAP; Buffer mapping error. 

ERSMKD;: F11-ACP could not mark file for deletion. 

ERSMRN; MRN value=neg or relative key>MRN. 

ERSMRS; MRS value=@ for fixed length records. Also @ for 
relative files. 

ERSNAM: NAM block address’' invalid (NAM=@, or not 

| accessible). 

ERSNEF; Not positioned to EOF (Sequential files only). 

ERSNID; Cannot allocate internal index descriptor. 

ERSNPK; Indexed file; no primary key defined. 

ERSOPN; RSTS/E open function failed. 

ERSORD; XAB’S not in correct order. 

ERSORG; Invalid file organization value. 

ERSPLG; Error in file’s prologue (reconstruct file). 

ERSPOS;: POS field invalid (POS>MRS,STV=XAB indicator). 

ERSPRM; Bad file date field retrieved. 

ERSPRV; Privilege violation (OS denies access). 

ERSRAB; Not a valid RAB (BID NOT=RBSBID). 

ERSRAC; Illegal RAC value. 

ERSRAT; Illegal record attributes. 


(continued on next page) 
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Value 
(Octal) 


134 


Table 4 (Cont.) 


MICCODE Field Values for Use with MACCODE 


Values of @, 1, 4, 5, 6, 


ERSRBF; 


ERSRER; 
ERSREX:; 
ERSRFA;: 
ERSRFM; 
ERSRLK; 
ERSRMV: 
ERSRNF;? 
ERSRNL; 
ERSROP; 
ERSRPL: 
ERSRRV: 
ERSRSA; 
ERSRSZ:; 


ERSRTB; 
ERSSEQ; 


ERSSHR; 


ERSSIZ; 
ERSSTK; 
ERSSYS; 
ERSTRE; 
ERSTYP:; 
ERSUBF; 


ERSUSZ; 
ERSVER; 
ERSVOL; 
ERSWER; 
ERSWLK; 
ERSWPL; 
ERSXAB; 
BUGDDI; 
CAA : 
CCF : 
CDA : 
CHN : 


DNA 
DVI 
ESA 
FNA 
FSZ 
IAL 
KFF 
LNE 
NOD 
NORMAL; 


~e se ~e “6 we ~e ~e “8 WO 


OK DUP; 


and 7 Octal 


Error/Reason 


Invalid record buffer address not 
word-aligned if BLK-IO). 

File read error. 

Record already exists. 

Bad RFA value (RFA=@). 

Invalid record format. 

Target bucket locked by another stream. 

RSX-F1l ACP remove function failed. 

Record not found. 

Record not locked. . 

Invalid record options. 

Error while reading prologue. 
Invalid RRV record encountered. 
RAB stream currently active. 
Bad record size (RSZ>MRS, or 
length records). 

Record too big for user’s buffer. 
Primary key out of sequence 
SPUT). 

SHR field invalid 
sequential files). 
SIZ field invalid. 
Stack too big for Save area. 

System directive error. 

Index tree error. 

Error in file type extension on FNS too big. 
Invalid uSer buffer addr (@, ODD, or if BLK-IO 
not word aligned). 
Invalid user buffer size 
Error in version number. 
Invalid volume number. 
File write error (STV=Sys err code). 

Device is write locked. 

Error while writing prologue. 

Not a valid XAB (@XAB=ODD,STV=XAB indicator). 
Default directory invalid. 

Cannot access argument list. 

Cannot close file. 

Cannot deliver AST. 

Channel assignment failure (STV=sys err code). 
Terminal output ignored due to (CNTRL) O. 
Terminal input aborted due to (CNTRL) Y. 
Default filename string address error. 

Invalid device I.D. field. 

Expanded string address error. 

Filename string address error. 

FSZ field invalid. 

Invalid argument list. 

Known file found. 


(ODD, or 


NOT=MRS if fixed 


(RAC=RBSSEQ for 


for file (cannot share 


(USZ=@) . 


Logical name error. 


Node name error. 
Operation successful. 
Record inserted had duplicate key. 


(continued on next page) 
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Value 
(Octal) 


Table 4 (Cont.) 


MICCODE Field Values for Use with MACCODE 
Values of @, 1, 4, 5, 6 and 7 Octal 


OK IDX; 
OK RLK; 
OK RRV; 


CREATE; 
PBF : 
PNDING; 
QUO 
RHB 
RLF 
RSS 
RST 
SQO 
SUC 
SPRSED 
SYN 
TMO 
ERSBLK; 
ERSBSZ:; 
ERSCDR; 
ERSCGJ; 
ERSCOF; 
ERSJFN; 
ERSPEF: 
ERSTRU ; 


a i ek ee i. | ee . ee . ee | nF 


-ERSUDF; 


ERSXCL; 


a ee i ee et kn! 


Error/Reason 


Index update error occurred-record inserted. 
Record locked but read anyway. 

Record inserted in primary o.k.; may 
accessible by secondary keys or RFA. 
File was created, but not opened. 

Bad prompt buffer address. | 

Async. operation pending completion. 
Quoted string error. © 

Record header buffer invalid. 

Invalid related file. 

Invalid resultant string size. 

Invalid resultant string address. 
Operation not Sequential, 

Operation successful. 


not 


Created file superseded existing version. 


Filename syntax error. 

Time-out period expired. 

FBSBLK record attribute not supported. 
Bad byte size. 

Cannot disconnect RAB. 

Cannot get JFN for file. 

Cannot open file. 

Bad JFN value. 

Cannot position to end-of-file. 

Cannot truncate file. | 
File is currently in an 
is denied. 

File must be opened for excluSive access. 
Directory full. 

Handler not in system. 

Fatal hardware error. 

Attempt to write beyond EOF. 

Hardware option not present. 

Device not attached. 

Device already attached. 

Device not attachable. 

Sharable resource in use. 

Illegal overlay request. 

Block check or CRC error. 

Caller’s nodes exhausted. 

Index file full. : 


undefined state; 


File header full. 


Accessed for write. 

File header checksum failure. 
Attribute control list error. 

File already accessed on LUN. 

Bad tape format. 

Illegal operation on file descriptor block. 
Rename; 2 different devices. 

Rename; new filename already in use. 
Cannot rename old file system. 

File already open. | 
Parity error on device. 


(continued on next 
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be 


access 


page) 


Value 
(Octal) 


Table 4 (Cont.) 


MICCODE Field Values for Use with MACCODE 


Values of 90, 1, 4, 5, 6, 


SPL ° 
NMF : 
CRC : 
BUGDAP; 
CNTRLC; 
DFL : 
ESL 


tH 
a 
> 
~=e 06 ~ ~= ~ =e & ~ 


MBC; 
NET; 
OK ALK; 
OK DEL; 
OK LIM; 
OK NOP; 
OK RNF; 
PLV ; 
REF; 
RSL: ; 
RVU i; 
SEG; 


= 
c 
oO 


and 7 Octal 


Error/Reason 


End of volume detected. 

Data over-run. 

Bad block on device. 

End of tape detected. 

No buffer space for file. 

File exceeds allocated space -- no blks. 
Specified task not installed. 

Unlock error. 

No file accessed on LUN. 

Send/receive failure. 

Spool or submit command file failure. 

No more files. 

DAP file transfer checksum error. 

Quota exceeded 

Internal network error condition detected. 
Terminal input aborted due to (CNTRL) C. 

Data bucket fill size > bucket size in XAB. 
Invalid expanded string length. 

Tllegal bucket format. 

Bucket size of LAN NOT = IAN in XAB. 

Index not initialized. 

Tllegal file attributes (corrupt file header). 
Index bucket fill size > bucket size in XAB. 

Key name buffer not readable or writeable in XAB. 
Index bucket will not hold two keys for key of 
reference. 

Multi-buffer count invalid (negative value). 
Network operation failed at remote node. 

Record is already locked. 

Deleted record successfully accessed. 

Retrieved record exceeds specified key value. 
Key XAB not filled in. 

Nonexistent record successfully accessed. 
Unsupported prologue version. 

Illegal key-of-reference in XAB. 

Invalid resultant string length. 

Error updating rrv’s, some paths to data 
lost. 


may be 


Data types other than string limited to one 
segment in XAB. 
Reserved 


Operation not Supported over network. 

Error On write behind. 

Invalid wildcard operation. 

Working set full (can not lock buffers in working 
set). 

Directory listing--error in reading 
name, directory name, of file name. 
Directory listing--error in reading 
attributes. 
Directory listing--protection violation in trying 
to read the volume-set, directory or file name. 


volume-set 


file 


(continued on next page) 
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Table 4 #£=(Cont.) 
MICCODE Field Values for Use with MACCODE 
Values of @, 1, 4, 5, 6, and 7 Octal 


Value | Error/Reason 
(Octal) | 


Directory listing--protection violation in trying 
to read file attributes. 

Directory listing--file attributes do not exist. 
Directory listing--unable to recover directory 
list after Continue Transfer (Skip). 

Sharing not enabled. 

Sharing page count exceeded. 

UPI bit not set when sharing with BRO set. 

Error in access control string (poor man’s’ route 
through error). 

Terminator not seen. 

Bad escape sequence. 

Partial escape sequence. 

Invalid wildcard context value. 

Invalid directory rename operation. 

User structure (FAB/RAB) became invalid during 
operation. : 

Network file transfer mode precludes operation. 


® 
’ 
e 
v 
® 
v 
e 
, 


=e | 6©™6 6G UME UO 


=o 


~e 


User defined errors 


=e 


Table 5 
MICCODE Field Values 
(with MACCODE Value of 12 Octal) 


Value 
(Octal) Error/Reason 


NOTE 


MICCODE Format: Bits @-11l contain the message 
type number. 


Unknown message type 

Configuration message 

Attributes message 

Access message 

Control message 

Continue Transfer message 

Acknowledge message 

Access Complete message 

Data message 

Status message 

Key Definition Attributes Extension message 
Allocation Attributes Extension message 
Summary Attributes Extension message 

Date and Time Attributes Extension message 
Protection Attributes Extension message 
Name message 

Access Control List Extended Attributes message 
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3.12 Key Definition Attributes Extension Message 


Each key is defined by a group of 19 fields. | The form of the _ key 
definition message is: 


KEYDEF : The operator field with TYPE = 19. 


KEYMENU(EX-6) : BM The following bit map specifies which of the 
following fields are present in this message. 
These fields and only these fields may appear in 
the message and they must be in the order 
specified. 


Meaning (When Set) 


FLG 
DFL 
IFL 
NSG, POS and SIZ 


4) 
il 
2 
3 
4 
5 
6 
7 
8 
9 


(reserved) 


FLG(EX-3) : BM Key option flag 


bit @ XBSDUP duplicates allowed 


bit l : XBSCHG allow keys to change 
bit 2 = XBSNUL null key character defined 
DFL(2) : B Data bucket fill. 
IFL(2) : B Index bucket fill. 
NSG(1) : B Number of segments (max. 8) needed to define the 


key in the record. For each segment, there will 
be a POS, SIZ pair. For example, if NSG 
contains 3, the following sequence of fields 
would appear: 


POS(2) : B. Position of key in record by byte number. The 
first byte in the record is byte @. 


SIZ(1) : B Size of key in record in bytes. 


REF(1) : Bo Key of reference indicator. 
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KNM (I-40) :A Key name correspoding to key of reference (REF) 


| above. 
NUL(1) : B | Value of null key SRG eae. 
IAN(1) : B | Index area number. 
LAN(1) : B  tigweet level index area number. 
DAN(1) : B Data level area number. 
DTP(1) : B Data type. 
RVB(I-8) : B | Root VBN for key. 
HAL(I-5) : B Hash ateora enn value (reserved). 
DVB(I-8) : B First data bucket start virtual block number. 
DBS(1) : B Data bucket size field. 
IBS(1) : B Index bucket size field. 
LVL(1) : B Level of root bucket. 
TKS(1) : B Total key size. 
MRL(2) : B Minimum record length; the minimum record 


length in bytes which will totally contain the 
key field for the key described by this message. 


3.13 Allocation Attributes Extension Message 


Use the Allocation message when creating or explicitly extending a 
file to specify the character of the allocation. The form of the 
allocation message iS: 


ALLOC : | The operator field with TYPE = ll. 


ALLMENU(EX-6): BM The following bit map specifies which of the 
following fields are present in this message. 
These fields and only these fields may appear in 
the message. They must be in the order 
specified. 


Meaning (When Set) 


VOL 
ALN 
AOP 

LOC | 

RFI (reserved) 
ALQ 
AID 
BKZ 
DEQ 


OnNINU BP WDNHEF® 


VOL(2) : B Relative volume number of a volume set on which 
this area or file will be allocated. 
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td Z 


ALN (EX-4) 


AOP (EX-4) 


LOC (I-8) 


RFI (I-16) 


ALQ(I-5) 


B 


B 


BM 


BM 


Alignment options 


XBSANY =| No specified allocation 
placement. 

XBSCYL Align on cylinder boundary. 

XBSLBN Align to specified logical 


BLOCKS 

XBSVBN Allocate aS near aS possible to 
specified virtual block. 

XBSRFI Allocate as near as possible to 
specified related file. 


Allocation options 


XBSHRD If the requested alignment can 
not be done, return an error. 
Contiguous allocation reguired. 


XBSCTG 


XBSCBT Contiguous best try. The file 
will be created, but it will be 
contiguous only when it is 
possible. 


XBSONC Allocate space on any cylinder 


boundary. 


Allocation starting point. Value is as follows: 


If ALN = XBSCYL, LOC is the cylinder number 
where allocation is to start. 
XBSLBN, LOC is the logical block where 
allocation is to start. 
If ALN = XBSVBN, LOC is the virtual block near 
which allocation should start; 
@ (default) meanS as near. as 
possible to current EOF. 
If ALN = XBSRFI, LOC is a VBN but a VBN in the 
a related file. 


If ALN 


Related file I.D. (reserved). 


The amount of space in virtual blocks to be 
allocated. Returns actual size of allocation. 
For DISPLAY, returns size of area. 


Area I.D. The area number used to identify an 
area for reference by a key definition. 


Bucket Size for this area. 


The default extension quantity in virtual 
blocks. Specifies the amount of space to be 
added to the area whenever it is extended 
automatically. It overrides the DEQ in the main 
Attributes message. 
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3.14 Summary Attributes Extension Message 


The Summary Attributes Extension message comprises the fields 
described below. The accessed process optionally returns this message 
to the accessing process on a file open, file create, display of a 
file’s attributes or directory list. The format of the Summary 
Attributes Extension message is: 


where: | 
SUMMARY : | The operator field with TYPE = 12. 
SUMENU(EX-6) : BM The following bit map specifies which of the 
following fields are present in this message. 
These fields and only these fields may appear in 
the message and they must appear in the order 
specified. | 
Meaning (When Set) 
| NOK 
NOA 
NOR 
PVN 
NOK(1) : B Number of keys defined in file. 
NOA(1) : B Number of areas defined in file. 
NOR(1) : B | | Number of record descriptors in file. 


PVN(2) : B Prologue version number. 


3.15 Date and Time Attributes Extension Message 


The Date and Time Attributes Extension message is composed of the 
fields described below. This message is optionally returned to the 
accessing process by the accessed process on a file open, file create, 
display of a file’s attributes or directory list. The form of the 
message iS: | | 


DATIME | DATMENU | CDT RD? | EDT 


where: 
DATIME : The operator field with TYPE = 13. 
DATMENU(EX-6) : BM The following bit map specifies which of the 


following fields are present in this message. 
These fields and only these fields may appear in 
the message and they must appear in the order 
specified. , 


Meaning (When Set) 
CDT 
RDT 


EDT 
RVN 
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CDT(18) : A Date and time file created in Network Standard 
Time (NST). 


RDT(18) : A Date and time file last updated in NST. 
EDT(18) : A — Date and time file may be deleted in NST. 


The preceding three fields should be in the 
following format: 


dd-mon-yybhh:mm:ss 
where: 


dd is the day 
mon is a three letter abbreviation for the month 
as follows: 


JAN 
FEB 
MAR 
APR 
MAY 
JUN 
JUL 
AUG 
SEP 
OCT 
NOV 
DEC 


yy is the year 
b is blank (space) 
hh is the hour 
mm is the minutes 
ss is the seconds 


RVN(2) : B Revision number--the number of times the file 
has been modified. 


Network standard time (NST) 1S the time standard chosen for each 
network to effect synchronization of remote file access operations and 
their results. For example, if a user in London creates a file in New 
York with a deletion time of 2 a.m., does he mean 2 a.m. in London or 
New York? NST resolves this problem. NST may be local time (for 
example, for networks wholly contained in one time zone), GMT or some 
other agreed on time. 


3.16 Protection Attributes Extension Message 


Use the Protection Attributes Extension message when creating a file 
to specify the protection for that file. If this information is not 
present when creating a new file, the file will be created with the 
default protection of the accessed node. This message may also be 
used to return a file’s protection code to the accessing process on a 
file open, display of the file’s attributes or directory list. The 
format of the Protection Attributes Extension message is: 


PROTECT} PROTMENU} OWNER| PROTSYS;| PROTOWN; PROTGRP} PROTWLD 
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where: 


PROTECT 3 


PROTMENU (EX-6) : 


OWNER(I-4@) : 


PROTSYS (EX-3) 


PROTOWN (EX- 3) 


PROTGRP (EX-3) 


PROTWLD (EX-3) 


A 


e 
e 


BM 


BM 


BM 


BM 


BM 


The OPERATOR field with TYPE = 14. 


“The following bit map specifies which of the 
following. fields are present in this message. 


If the field is not present, the default, if 
any, should. be. used. These fields and only 
these fields may appear in the message and they 
must appear in the order specified. 


| Meaning (When Set) 


OWNER 
PROTSYS 
PROTOWN 
PROTGRD 
PROTWLD 


The name or user code (for example, UIC such as 
249,220) of the file owner. When creating a 
file and when the file system allows the owner 
to be user-specified, this field, if present, 
specifies the owner of the file. If this field 
is not present, the file owner information is 
taken from the user identification information 
which comes with the connect. Alternatively, if 
the User Identification message is being used 
(see Appendix A) owner information may be taken 
from it. 


File protection for system access rights. 
Meaning (When Set) 


Deny read access. 

Deny write access. 

Deny execute access. 
Deny delete access. 
Deny append access. 
Deny directory list access. 
Deny update access. | 
Deny change access protection 
attribute. : 

Deny extend access. 


g 
1 
2 
3 
4 
5 
6 
7 


© 


File protection for file owner access’ rights. 
Refer to the bit map used for PROTSYS above. 


File protection for group access rights. Refer 
to the bit map used for PROTSYS above. 


File protection for general (world) access. 


Refer to the bit map used for PROTSYS above. 
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3.17 Name Message 


Use the Name message when renaming a file to contain the new name the 
file will have after the operation is complete. Use the Name message 
with the directory listing to return the name of each file for which 
attributes are returned. It may also be used when opening or creating 
a file to contain the default or related file specification. The form 
of the name message is: 


NAME | NAMETYPE | NAMESPEC 
where: 
NAME: The operator field with TYPE = 15. 


NAMETYPE(EX-3) : BM Type of name contained in NAMESPEC field. 


File specification 
File name 
Directory name 


Volume or structure name 
Default file specification 
(reserved) 

Related file specification 
(reserved) 


NOTE 


Here the file specification means’ the 
full file specification including the 
volume, directory, and file name. 


NAMESPEC(I-28@) : A The file specification in the format of the 
remote node. This ASCII field is not 
interpreted by DAP software. 


3.18 Access Control List Attributes Extension Message (Reserved for 
Future Use) 


The Access Control List (ACL) message specifies a list of users. and 
the access rights they have to this file. Each ACL entry is in the 
format of the system where the file resides. The list is potentially 
very long and therefore this message has a facility for specifying if 
this is the last of a sequence of ACL messages. The form of the ACL 
message 1s: 


ACLTYPE| ACLCNT [ACL...] 


ACLTYPE : The operator field with TYPE = 16. 


ACLCNT(1) : B The absolute value of this field is the number 
of repetitions of the ACL field in this message. 
If this field contains a negative value, this is 
the last in a sequence of ACL messages. 


ACL(I-8@) : A Access control list entry. There is one entry 
for each user having access to the file. This 
field is treated as a literal string (not parsed 
by accessing system) and is in the format of the 
accessed system. 
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4.0 FILE ORGANIZATION 


4.1 Types of Files 


The following types of files are addressed by this specification: 


Sequential. Each record’s position depends on the position of 
the previous record. 


Relative. Each record in the file has a unigue identifying 
number, its record number. Records may be accessed randomly 
by specifying their record number in a Control message. 


Hashed/Indexed. These files have records organized according 
to some classification method, usually an access key. Within 
a particular key for indexed files, the records are assumed to 
be logically sequential. 


4.2 Record Formats and Attributes 


There are two ways in which ASCII records are stored in DIGITAL file 


systems: 


1. 


Byte Count. A byte count associated with the record in the 
file indicates how long the record is and is_ used to 
determine record boundaries. 


Stream. The ASCII record is stored exactly as is. The 
record is assumed to be terminated with one of the following 
delimiters: 


a. (FF) -- Form feed 

b. (DLE) -- Data link escape 
Cs (DC1) 

d. (DC 2) 

e. (DC3) 

ae (DC4) 

oe (VT) -- Vertical tab 

h. (LF) -- Line feed 

is (ESC) -- Escape 

Ave (“Z) -- Control Z 


Files using ASCII stream often do not have record attributes 
stored with the file. 


DAP supports four ASCII record formats: 


Ls 


2. 


Fixed length records 
Variable length records 
Variable with fixed control 


ASCII stream 
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In addition, DAP supports the following eight attributes: 
1. FORTRAN carriage control 
2. COBOL carriage control 
3. Print file carriage sonteel 
4. Implied LF/CR envelope for printing 
5. Embedded carriage control 
6. Line sequential ASCII 
7. MACY11 


8. None of the above 


4.2.1 Handling Stream ASCII -- Stream ASCII files consist of a string 
of ASCII characters with no explicit record structure imposed upon the 
data within the file. Records in a stream ASCII file are defined by a 
set of delimiters (see Section 4.2) where each record is terminated by 
one of the delimiters. DAP processes transferring stream ASCII data 
records perform no transformations upon the records. All characters 
in the records, up to and including the delimiter, are sent as a 
Single record in a DAP Data message. No characters, including NULLS, 
are Stripped or replaced. Stream ASCII files may have other 
attributes as well as stream ASCII, for example, FORTRAN carriage 
control. 


4.2.2 Conversions -- DAP does not specify data or format conversions 
that may be necessary when sending data from one type of system to 
another. It is the responsibility of the user process (accessing 
process) to make any necesSary conversions when transferring data 
between unlike systems. The accessed process (server) is 
non-intelligent and does only what it is told. The accessed process 
executes a protocol function only if it Supports that type of 
operation or attribute. If an accessed process does not support an 
Operation or attribute, it returnS an appropriate Status message. 
Thus, if a conversion must be made, for example, sending a Stream 
ASCII file to a remote system supporting variable length byte count 
records but not Stream ASCII, the accesSing process (user) must 
perform the conversion before sending each record of the file. 
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NOTE 


While this is not a part of the DAP 
Specification, the following algorithm 
has been used effectively in several 
DAP-speaking user processes to determine 
what (if any) conversions must be made 
when trying to store a file on a remote 
file system: | | 


1. Open file using file’s attributes on 
local system. 


2. If no error on Attributes message, 
send file and terminate, else go to 
step 3. 


3. Send new Attributes and Access 
Complete messages uSing the next 
most likely attributes to be 
Supported by the remote system... 


4, If no error on Attributes message, 
send file and terminate, else go to 
step 3. | 


This should almost never require 
more than two repetitions of step 3 
as most ASCII files are either 
Stream or variable with implied 
CR/LF. 


4.3 Data Formats 


4.3.1 Fixed-Length Records - All records are of the fixed length 
specified in the MRS field. They are delimited by physical message 
blocks (that is, the last byte in a Data message is. the end of the 
record). 


4.3.2 Variable-Length Records - These records are like the 
fixed-length records except the record length is variable with the 
maximum length being specified in the MRS field. 


4.3.3 Variable with Fixed-Control Format Records - These records are 
normal variable-length records with an associated fixed-length field 
used for control purposes. In DAP Data messages, this fixed-length 
control field immediately precedes and is contiguous with the variable 
part of the record. The length of the fixed field is found in the FSZ 
field in the Attributes message. MRS contains the maximum length of 
the variable portion only. FSZ + MRS = total maximum record length. 
Regardless of the type of the data in the variable portion of the 
record, the data in the fixed portion is always sent as a binary field 
contained in an integral number of 8-bit bytes. 
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4.3.4 ASCII Stream - Here a file contains just a stream of ASCII 
characters with no real concept of records. However, delimiters are 
used to terminate "records" for purposes of reading and writing’ the 
file. 


4.4 Supported Data Types 


The DATATYPE field of the Attributes message defines the code 
representation used to transfer data. These are: 


ASCII 
Image 
EBCDIC (Reserved) 


In addition, there is a COMPRESSION option mode, which can be used 
with any of the above. This compressed mode reduces the amount of 
data sent by encoding blanks and duplicates. 


4.4.1 ASCII - This is the 7-bit ASCII code-set as defined in the 1968 
ANSI standard. To transmit this within 8-bit frames, the high order 
bit is ignored except when uSing 7-bit compression. On card readers, 
this refers to the ASCII encoding of the punches’ into the 128 
character codes. 


4.4.2 EBCDIC - this is an IBM 8-bit EBCDIC code set. (Reserved) 


4.4.3 Image - This is a mode for transmitting data in DAP where no 
code set is specified and data records (or blocks) are simply regarded 
as ordered strings of bits. The number of bits in a bit String (image 
mode record) need not be a multiple of 8 although the bit strings are 
in fact transmitted in 8-bit frames (a requirement of lower level 
protocols). 


When transmitting Image data, if the number of data bits in the 
message is not amultiple of 8 (the number of actual data bits in a 
DAP Data message must be a multiple of the byte size as specified by 
BSZ in the Attributes message), the field BITCNT in the header of the 
Data message must be used. The BITCNT field specifies the number of 
bits in the final 8-bit frame of the Data message which are not actual 
data bits. The non-data bits are padding bits required to fill out 
the 8-bit frame. 


When transferring bit strings where the bit count is a multiple of 8, 
it is not necessary to use BITCNT. 


5S 


The order in the bit strings is low order bit of low order byte first, 
second ‘bit of low byte, and so on, followed by the same sequence for 
successively higher order bytes. For example, consider retrieving the 
3 byte record with 6-bit bytes shown below. The order of the string 
is as shown below with the first bit on the right and the last bit in 
the string on the left (the top row of single digit numbers inside the 
boxes 1s byte numbers and the bottom row is bit numbers. Thus for any 
bit position in the string, the top digit gives the byte and the 
bottom digit the bit within that byte)... 


In Image record mode, this string transmits in 3 8-bit frames in a DAP 
Data message as follows: 


xxxxxx22/22221111 1 @ 000 
54/ 32195432 05 g 


Qg 
21 
with frame 9 being transmitted first, low order bit first. The xs 
are padding. BITCNT is 6 for this DAP Data message. 


1 1 0 
4 1 4 3 


If this image record is being sent to a system which stores data in 
7-bit bytes, this record is stored as follows: 


4.4.4 Compression - Any of the encodings, even the Image mode, may be 
compressed on transmission to eliminate the sending of duplicates and 
multiple blanks. The compression technique is slightly different with 
7-bit and 8-bit character encodings. , 


7-bit compression: 


1. Send non-compressed characters with high order bit = 9Q@ and 
low 7-bits = character: (9) (7-bit char). 


2. Send blanks as high bits = 18 followed by number of blanks in 
6-bit binary: (18) (number blanks). 


3. Send repetitions as high bits = 118 followed by number of 
repetitions in 5-bit binary: (118) (number reps) followed by 
the repeated character. 


4. An escape scheme allows sending of 12-bit card images when 
they do not encode into the ASCII code set by sending high 
bits = 1111 followed by columns 12-1 and another character of 
columns 2-9. For example, send (1111) (12,11,8@,1) in the 
first character and (2,3,4,5,6,7,8,9) in the second 
character. 
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5. The high bit Sequence 11180 has been reserved for future 
expansion. 


6. In the case of repetitions the repeated character may be a 
12-bit image which is sent as 2-characters. 


7. Summary 7-bit compression: 


OxxxxXxXxXxX 7-bit non-compressed characters 

1Oxxxxxx number of blanks (the character octal 490) 
110xxxxx number of repeated characters 

L1lllxxxx 12-bit card image 

XXXXXXXX 12-bit card image (continued) 

1110xxxx reserved 


8-bit compression: 


With 8-bit codes the blanks, repetitions and 12-bit card image are the 
7-bit case. Precede 8-bit non-compressed strings by a 
count of the string length with high bit = @ followed by 7-bit count: 


same as 


(09) (count). 


This is followed by "count" 8-bit characters. Following 


this may be another string, blanks or repetitions. 


Summary: 
Oxxxxxxx number of non-compressed characters 
1@xxxxxx number of nulls (all zero bytes) 
110xxxxx number of repetitions | 
1110xxxx reserved 
Jlllxxxx 12-bit card image | 
XXXXXXXX 12-bit card image (continued) 


The receiver of compressed data must be able to expand it according to 


the rules 


Just given. 


Do not use data compression unless the 


Configuration messages from both systems indicate they both support 


file compression 


(bit 15). The compressed format bit of the DATATYPE 


Field in the Attributes message indicates the use of file compression. 
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5.0 OPERATION 


DAP transfers data to and from I/O devices and mass_ storage files 
independent of the I/O Structure of the system being accessed. This 
transfer is accomplished by communication with a DAP process’ that 
accepts DAP requests on the network side and translates them into 
equivalent requests to the local I/O system. From the network it 
appears as if DECnet systems support DAP messages directly within 
their file systems. | 


DAP provides the mechanism for setting up the conversation path for 
remote file access, transferring data over the link, and terminating 
the logical link. a 7 : 


5.1 Setting up the Link 


Processes that implement the DAP protocol operate at the application 
level within a DECnet system. They use the lower level interprocess 
communication facilities of the network for the creation and flow 
control of the data path (logical link) between the processes 
exchanging messages within the DAP environment. Once the link is 
established, the processes may exchange DAP messages over the link. 


Each remote file access in progress uses a separate logical link. 
This means a_ single user cannot access more than one file at a time 
over a Single logical link. It also means that several users cannot 
access the same file over a single logical link. However, a single 
logical link can be used to access more than one file provided access 
to the files is sequential and does not overlap. 


A lower level interprocess communication protocol passes access 
control information (user identification, password, and account 
identification) from the accessing (user) DAP process to the accessed 
(server) DAP process. | ps 


Following link establishment, the DAP-speaking processes exchange 
Configuration messages. The purposes of this exchange are: 


1. To establish the maximum buffer size for exchanging lower 
level protocol messages 


2. To identify system type to each other 


3. To enable one DAP process to know which version of the 
protocol the other DAP process speaks 


4. To inform the opposite process of the generic capabilities of 
the system sending the message 


The system type is used when it is necessary to know the type of both 
the operating system and the file system on the other end of the link. 
This is helpful, for example, in deciding if block mode file transfer 
can be used when transferring files between like systems or if 
multiple data streams can be initiated as is possible between 
RMS-based systems. 


The capabilities field of the Configuration message indicates to each 
of the DAP processes the generic capabilities of the other DAP process 
with which it iS communicating. This field determines the type of 
file support offered by a remote system without resorting to trial and 
error techniques. 
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The node where the file or device resides is the accessed node _ while 
the node where the user process is located is the accessing node. The 
accessing process initiates the connection. For each DAP message sent 
over the link, a transmit request and corresponding receive request 
must be issued to Session Control (DNA Session Control Functional 
Specification). This document explains the DAP messages only and 
assumes that the necessary receives and transmits are issued by the 
processes involved. 


After link creation and the exchange of Configuration messages, the 
accessing process sends an Attributes message, optionally followed by 
One Or more Extended Attributes messages, specifying the mode _ and 
format of the data and the structure of the file. This is then 


followed by an Access mesSage specifying the desired operation. The 
Access message may be preceded by a Name message if the default 
filename option is required. The Attributes, Extended Attributes, 


Name, and AccesS messages may be blocked and sent together in one 
transmission if buffer space is available (the LENGTH field must be 
used) and if blocking iS Supported as indicated by the Configuration 
message. Alternately, if a DAP message is too long to be sent as a 
Single entity due to limitations of the underlying Transport 
mechanism, the DAP message may be Segmented and sent in two or more 
pieces (see FLAGS field in message header) if segmentation is 
Supported. 


Systems not retaining the file attributes use the Attributes message 
to set the attributes for the transfer. When creating a new file, the 
Attributes message sent by the accessing process specifies the 
attributes the new file should have. If the accessed system does not 
Support these attributes, it returns a Status message to that effect. 
When storing records with systems retaining attributes, the accessing 
system uses the Attributes message returned by the accessed system to 
indicate the attributes the records being sent should have. For 
record retrieval with systems retaining attributes, records are 
transferred with the attributes of the Attributes messages returned by 
the accessed process. 


After the initial set up messages are sent, the accessing system 
receives a response from the accessed process. If the access 
Specified opens a file, an Attributes message and Extended Attributes 
messages followed by an Acknowledge message is sent from the accessed 
system containing the actual attributes of the accessed file. If the 
operation specified in the Access message deletes, renames or executes 
a file, no Attributes messages or Acknowledge messages are returned 
and the response is an Access Complete message. 


To minimize the tying up of network resources (Such as logical links 
and buffers), the Configuration, Attributes, Extended Attributes, 
Name, and Access messages should be sent in a timely manner. A _ timer 
may be set for each message and if it does not arrive in a reasonable 
time the link may be disconnected by the accessed process. After the 
Acknowledge message has been received, the file is open and the 
accesSing process sets the pace for access of the file. 


If there are errors in the setup procedure, a Status message will be 
returned. 


NOTE 


A receive must always be outstanding in 
order to accept both expected and 
unexpected DAP Status messages. Status 
messages are always sent as ordinary 
(not Interrupt) messages. 
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If an error is detected in a Status message, either during Or after 
setup, a protocol error has occurred and there is nothing that can be 
done to recover so the link should be disconnected. 


Errors in exchanging eoneioureti ch messages should be very rare Since 
the information in Configuration messages will generally be "canned" 
and of an informative nature. If the accessed system detects an error 
in the Configuration message, it returns a Status message and the 
accessing system can either retry or disconnect. If the accessing 
system detects an error, it disconnects. 7 


NOTE 


If, however, a Configuration message 
appears to be in error because the 
SYSCAP field is too long and the DAP 
version number is greater than that to 
which the current software is written, 
assume that the SYSCAP field has been 
extended in the later version of DAP. 


Ignore this error. This is the only 
time when an error is ignored. The 
assumption is that the more 


sophisticated DAP process uses only a 
Subset of the protocol and thus both 
sets of software can work together. 


5.1.1 Errors in the Setup Sequence - The accessed process returns a 
Status message for errors detected in each message (Configuration, 
Attributes, Name, and Access). On receiving an error in response _ to 
one of these messages, there are three possibilities open to the 
accessing DAP process: 


l. Disconnect the link. 


2. Send the corrected message responsible for the error. There 
is no point in sending the original message unless there is 
sufficient doubt that the message was delivered properly or 
that the error indicated was of a temporary nature. For 
example, an attempt was made to open a file already open by 
another process. 


3. Start a different access. A new access usually starts with 
an Attributes message, but it could start with an Access 
message (where the type of access does not require attributes 
such as ERASE) or even a Configuration message. 


If the user process tries to recover by sending a corrected message or 
Starting a new access, the accessed DAP process can accept any of the 
setup messages in response to a Status mesSage. Table 6 contains a 
list of responses to setup message errors. In this table, Extended 
Attributes messages are considered as being Attributes messages. and 
Name messages part of the Access message. When recovering from an 
error in an Attributes Extension message, the accessing process spear 
back up to the Attributes message. 
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Table 6 
Responses to Setup MesSage Errors 


Responses 


Configuration Attributes Access 
Message Message Message 


Configuration Message 


Attributes Message 


Access Message 


Invalid response. 

Valid response. 

Valid response only for accesses requiring no 
attributes message. 


Errors detected by the accessing process in Attributes, Extended 
Attributes, Name and Acknowledge messages. cause the accessing process 
to disconnect the logical link thus terminating the access. 


5.1.2 Setup Sequence - If a timer is used between setup messages, 
this same timer should be set by the accessed process after an error 
during setup. If the timer expires, a disconnect should be initiated. 


The following conventions are used in DAP mesSage Sequence diagrams in 
this and subsequent sections: 


e Brackets [ ] denote optional messages. 


e Messages on the left side of the arrows are from the accessing 
process. 


@e Messages on the right side of the arrow are sent by the 
accessed process. 


NOTE 


The message sequence diagrams in this 
and subsequent sections are not 
definitive. However, although they do 
not cover every Situation that can arise 
with DAP remote file access, they should 
be complete enough to give an idea of 
what should be done in those situations 
not explicitly addressed. | 
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After a logical link is established, the setup sequence is as follows: 


1. Configuration information exchange: 


CONFIGURATION<~------ >CONFIGURATION 
NOTE 
Both accessing and accessed processes 
can send Configuration messages 
immediately on link establishment. The 
accessing process must send its 


Configuration message immediately. 


2. Setup for access: 


ATTRIBUTES------ > 
[EXTENDED 

ATTRIBUTES] ----> 
[NAME--~------~-- > 


(DEFAULT) ] 


KCCESSaeeaceSoass 
| | Secon ATTRIBUTES 
[EXTENDED 
Peden ATTRIBUTES] 
ooo [NAME (EXPANDED FILESPEC) ] 
Sess ACKNOWLEDGE 
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NOTES 


An Attributes message is not 
reguired when the Access’ message 
specifies ERASE, RENAME, DIRECTORY 
LIST, or EXECUTE command file. For 
these types of access, the accessed 


process returns neither the 
Attributes message nor the 
Acknowledge message unless 
specifically requested by the 


DISPLAY field. If the DISPLAY field 
iS omitted from the Access message 
and the function is OPEN, CREATE, or 
SUBMIT, the accessed process returns 
a Main Attributes message. When a 
DISPLAY field iS present in an 
Access message, the accessed process 
returns only the messages requested 
by the DISPLAY field. When RENAME 
is specified, follow the Access 
message by a Name message containing 
the new name for. the file (see 
Section 5.2.8). 


Request the optional Name message 
returned by the accessed process 
after opening the file by setting a 
bit in the DISPLAY field of the 
Access message. The Name message 
contains the file specification of 
the file opened or created after all 
the logical names have been resolved. 


and defaults applied. 


3. Error in Configuration messages: 


(a) 


Disconnect after error detected: 
CONF IGURATION-----~-- >(error detected) 
i tateahatans STATUS 
DISCONNECT 
or 
Correcting erroneous message: 
CONF IGURATION------>(error detected) 
(== STATUS 
CONF IGURATION------ > 
Or 
If the error is in the returned message: 
CONF IGURATION------> 
(in error) {------ CONFIGURATION 


DISCONNECT 
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4. 


Error in Attributes message: 
(a) Disconnect after erroneous message: 
ATTRIBUTES------> (error detected) 
| <= -STATUS 
DISCONNECT | 
or 
(b) Correcting erroneous message: 
ATTRIBUTES------ >(error detected) | 


¢~-----STATUS 


Or 
(c) Starting a.new remote file access on the same link. The 
new access shown must be one not requiring the Attributes 
message as no valid attributes are currently in effect (the 
former Attributes message contained an error). See Note 1 in 
Section 5.1.2. | | 
ATTRIBUTES------ >(error detected) 
(=== STATUS 


ACCESS Sars > 


Error in Optional Extended Attributes message: 
(a) Disconnect after erroneous message: 
ATTRIBUTES------ > 


EXTENDED 
ATTRIBUTES l]----- > 


EXTENDED 
ATTRIBUTES n-~---- >(error detected) 


<------STATUS 
DISCONNECT 


Or 
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(b) Correcting erroneous mesSage (note that restart backs up 
to the Attributes message) : 


ATTRIBUTES------ > 


EXTENDED 
ATTRIBUTES l----- > 


EXTENDED 
ATTRIBUTES n----- >(error detected) 


{=e sS35 STATUS 
ATTRIBUTES-—-—--—--— > 


EXTENDED 
ATTRIBUTES 1----- > 


EXTENDED 
ATTRIBUTES n----- > 


ELCs 


(c) Starting new access on Same link: 


ATTRIBUTES-------- > 

EXTENDED 

ATTRIBUTES l------ > 

EXTENDED 

ATTRIBUTES n------ >(error detected) 
€(3e---- STATUS 

ACCESS =—s-_- -=----- > 


6. Error in Name message for default file specification: 
(a) Disconnect after erroneous message: 
NAME —-----> (error detected) 
(=== S== STATUS 


DISCONNECT 
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(b) Correcting erroneous message: 
NAME ------> (error detected) 


<------STATUS 


(c) Starting new access on same link: 


NAME fo aeeeeaai >(error detected) 
<------STATUS 

ATTRIBUTES  ------ > 

[NAME 9 ====== >] 

ACCESS —-—_—«_ ot eH > 


7. Error in Access message: 


(a) Disconnect after erroneous message: 


ATTRIBUTES--~--- > 
ACCESS  ——_ w= -- = >(error detected) 
(Sao >Sr STATUS 
DISCONNECT------> 
or 


(b) Correcting erroneous message: 


ATTRIBUTES------ > 
ACCESS —-—- == ---- >(error detected) 
¢------STATUS 
ACCESS = -=---- > 
or 


(c) Starting new access on same link with new Attributes and 
Access messages: 


ATTRIBUTES------ > 

ACCESS  —-_- = ----- >(error detected) 
(2----- STATUS 

ATTRIBUTES-----=-> 

ACCESS ~ --~---- > 
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5.2 Transferring Data Over the Link 


The message exchange sequence for transferring data over the link 
depends on the direction of data flow with respect to the accessing 
and accessed systems. Data may be sent to the accessing node as in a 
retrieve operation or from it as in a store operation. 


Before data transfer can start, however, a data stream must be 
initiated by sending a Control message (SCONNECT) after the file is 
open. With file systems that support multiple data streams, 
additional data streams can be initiated with more Control messages. 
Multiple data streams are differentiated by using the STREAMID number. 
Data messages for a particular data stream must have the same STREAMID 
number as the Control message that initiated the data stream. If the 
STREAMID number is omitted, a default of 8 is used. 


The sequence for initiating a data stream is as follows: 
CONTROL (CONNECT) ----> 
<----ACKNOWLEDGE 
If an error occurs, a Status message is returned instead of an ACK. A 
new data stream can be initiated any time the file is open by using 
the above message sequence. 


NOTE 


Multiple data streams cannot be used if 
file transfer mode is specified in the 


RAC field of the Control message. The 
file transfer mode implies a single data 
stream with only data (no control 


messages) flowing over the link. By 
eliminating Control messages, efficiency 
is gained. 


There are three classes of Status message which can be sent by _ the 
accessed process during data transfer: 


1. Successful. The accessed process returnS a success Status 
message for data transferred when not in file transfer mode. 
The successful Status messages synchronize DAP processes and 
return information to the user. 


In file transfer mode, data is pipelined, and_ successful 
Status messages are omitted for efficiency. 


2. Warning. This class of Status message iS sent to the 
accessing process when an operation completes without 
complete success. For example, this message is sent if a 
record was inserted in an indexed file that had a duplicate 
key. Warning StatuS mesSsageS are always sent to the 
accessing process provided the Configuration message states 
the accessing process supports them. After sending a warning 
Status message, the accessed process suspends processing on 
that data stream until it receives a Continue Transfer 
message (or the next Control message for Record Retrieval) 
instructing it to reSume processing or an Access Complete 
message terminating the access. On receiving a warning 
Status message, the accessing process either sends a Continue 
Transfer (Resume) to continue data transfer, a Control 
message, or an Access Complete if it wants to terminate the 
access. 
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3%. EYEOr. This class of Status message is sent when an 
operation waS unable to complete at all, for example, if 
there were a read error. When an event in this claSsS occurs, 
a Status message iS always sent to the accessing process. 
After sending the Status message, the accessed process 
suspends processing on that data stream until it receives a 
Continue Transfer message telling it what to do or an Access 
Complete message terminating the access. On receiving an 
error Status mesSage, the accesSing process either sends an 
Access Complete to terminate the access or a Continue 
Transfer if it wants to attempt recovery. 


These three classes of Status message are differentiated by the 
MACCODE field of the Status message (see Section 3.11 and Table 2). 
Status codes returned by the file system often assist in determining 
which class of Status message, if any, should be sent on the 
completion of each operation. However, ultimate responsibility for 
the classification and mapping of file system status codes into DAP 
Status messages resides with those who implement DAP server (accessed) 
processes. The following subsections contain examples of the handling 
of both warning and error Status messages. 


5.2.1 Sequential File Retrieval - For sequential file retrieval, the 
accessed system sends data records. Once the initial startup sequence 
is completed and the data stream initiated, a single Control message 
(Get) is sent to start data records flowing. Thereafter, the file 
records are transmitted without waiting for any further DAP messages 
to control sending messages. The lower level protocols perform all 
flow control. 


To specify sequential file retrieval, the accessing process specifies 
Sequential file access (or virtual block number file transfer) in the 
Control (Get) message. The accessed process then sends file records 
(or blocks) without waiting for any further DAP Control messages. In 
contrast to sequential file retrieval, if sequential record access is 
specified, the accessing process must send a Control message for each 
record retrieved. 


Data messages continue to arrive until one of the following occurs: 


e The end-of-file is reached on the accessed system. 
-@ An error occurs in accessing the file. 
e The accessing system decides it has completed its access. 


In the first case, the last record sent in a data message is followed 
by a Status message with end-of-file detected set. In the second 
case, a Status message is sent when an error occurs in accessing the 
Original file. 


If the accessing system receives a Status message with end-of-file, it 
sends an Access Complete message and waits for an Access Complete 
(Response). It then either disconnects or initiates another access by 
sending a setup sequence. If the accesSing process receives a Status 
message with either an error or warning, it may either send an Access 
Complete Command and wait for an Access Complete (Response) or try to 
recover with a Continue Transfer. | 
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If the accessing system decides to terminate access. prior to 
end-of-file, it sends an Access Complete (Close) and waits for an 
Access Complete (Response) in return. In Such cases, an accessing 
system issuing an Access Complete (Close) may still receive one or 
more records for the file, an end-of-file indication or even a Status 
message due to the pipelining delay in the system. It should pass 
over these records until an Access Complete (Response) is received. 
It may then disconnect or access another file. : 


A number of possible sequential file retrieval sequences are 
diagrammed below. In each case, the accessing process sends the 
messages to the left of the arrows. The access process sends’ the 


messages to the right of the arrows. Optional messages are bracketed. 
1. Retrieval until End-of-File (EOF): 


CONTROL (GET) ------ > 
{------ RECORD 1 


<SSSS> RECORD n 


NOTE 
Transfer continues until End-of-File or 
error 
{------ STATUS (End-of-File) 


ACCOMP (CLOSE) ------ > 
<------ACCOMP (RESPONSE) 


The accessing process may now issue another 
access or disconnect the link. 
2. Retrieval until error or warning status: 
 lealeeteias RECORD n 
Co Teteateaatee STATUS 
NOTE 
The STATUS message occurs while trying 


to read record ntl. 


When an error is received, the accessing process can do. one 
of the following: 


(a) Request link termination. 
ACCOMP (CLOSE) -------- > 
{------ ACCOMP (RESPONSE) 
(b) Request the information be sent again 
CONTINUE (TRY AGAIN) ------ > 
| —  €------RECORD n+l 
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(c) Skip that record and continue 


CONTINUE (SKIP) ------ > 
mee RECORD n+2 __ 


(d) When a warning is received, the accessing process can 


request link termination as in (a) above or resume processing 
by sending a Continue Transfer (ReSume) message. | 


<{<\rcc- RECORD ntl 
3. Retrieval with access termination: 
<----RECORD m 
ACCOMP (CLOSE) ----> 

<----ACCOMP (RESPONSE) 
The accessed process may set a timer following sending Access 
Complete (Response). If neither a Disconnect or another 
message is received within the time interval, it may 
disconnect the link. 


4. Retrieval with checksum error on close: 


<-~---RECORD n 


<----STATUS (EOF) 
ACCOMP (CLOSE) ----> 

<----STATUS (checksum error) 
ACCOMP (CLOSE) ----> 


<----ACCOMP (RESPONSE) 


Do not send an Access Complete (Purge) to the accessed 
process as it purges the input file. Sending the Access 
Complete message with the CHECK field causes a comparison of 
the checksums. If the CHECK field is omitted, checking is 
by-passed. See Section 5.5.2. 


5.2.2 Sequential File Storage/Append - In the store case, data is 
sent to the accessed system. Following the initialization of the data 
stream, the accessing system sends a Control (Put) message to tell the 
accessed process what to do. The Control message is followed by file 
records using the Data message. The accessed system accepts’ these 
messages and continues until the accessing system sends an Access 
Complete (Close). This causes a corresponding Access Complete 
Response to be returned following successful file closure, or a Status 
message to be sent if an error occurs in closing the file or a 
checksum failure is detected. For other than a checksum failure, the 
access is concluded and another access may Start or the link may be 
disconnected. If a checksum failure is detected, another Access 
Complete (without the CHECK field) is sent, either close or purge, to 
terminate the access the way the user desires. 


To specify sequential file storage, the accessing process’ specifies 
sequential file access in the Control message together with Put. To 
specify sequential file append, the operations. are the same except 
"position to EOF" is specified in the Control message in addition to 
Put and sequential file access. As with sequential file retrieval, 
sequential file storage implies the use of only one data stream and no 
Control messages after the initial Control (Put) message. 
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Example 1 below shows an optional Access Complete (End-of-Stream) 
message flushing the pipeline before closing the file. This 
resynchronizes the accessing and accessed processes. Thus, error 
handling is easier if an error occurs in writing the final records to 
the file when the user issues a close command. After the error is 
returned to the user, he has the option of purging the file as the 
Access Complete (Close) is not yet in the pipe. 


If an error occurs during record transfer, the accessed system returns 
a Status message. This must always be replied to with a Continue 
message sent as an Interrupt message (because of possible pipelining). 
In addition, to terminate the access, send an Access Complete message. 


A list of sequential file storage sequences follows. In each sequence 
the accessing process sends the messages to the left of the arrows. 
The accessed process sends the messages to the right of the arrows. 


1. Store with no errors: 


CONTROL (PUT) = --==-- > 


RECORD 1 —  — meee = > 
NOTE 
Transfer continues’ until access is 


complete or error 


RECORD nN 2 eee > 
[ACCOMP (EOS) ------ >] 

(= S=— ACCOMP (RESPONSE) ] 
ACCOMP (CLOSE) . Se > 


Keo ACCOMP (RESPONSE) 
2. Error during transfer: 


(a) Purge the new file and terminate: 


RECORD n 3 37~— = ---=- > 

2 STATUS 
ACCOMP (PURGE) ------ > 
CONTINUE (ABORT) ------> (INTERRUPT) 


NOTE 


On receiving the Continue Transfer 
Interrupt message, the accessed system 
discards records until Access Complete 
(Purge) is received. It then purges the 
incomplete file and returns an Access 
Complete. | 


<SS==s= ACCOMP (RESPONSE) 
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(b) 


(c) 


(d) 


Close the new file and terminate:. 


ACCOMP (CLOSE) ------> 
CONTINUE (ABORT) ------> (INTERRUPT) 


NOTE 


The accessed system discards’ records 
until the Access Complete (Close) is 
received and then closes the incomplete 
output file. . 


CaS eein ACCOMP (RESPONSE) 


or 


Retry--the accessed system still has the record. 


caused the error in its buffer: 


CONTINUE (TRY AGAIN) ------ > (INTERRUPT) 
RECORD n+l ~——— ==> 


or 


Skip the record and continue: 


CONTINUE (SKIP) ------ > (INTERRUPT) 
RECORD n+l ------ > 
NOTE 


On an error, the accessed process does 
not issue any more receives’ after 
sending the Status message and _ before 
receiving the Continue message, which 
tells it what to do. If the accessing 
process responds to the error by sending 
an interrupt Continue Transfer (Retry) 
message and the retry is successful, the 
accessed process postS a receive and 
carries on with the data transfer. If 
the retry fails, another Status message 
is sent. A Continue message with skip 
always postS a receive and tries to 
carry on having skipped the record which 
caused the original error. For file 
transfer store Or append, continue. 
messages must be sent in interrupt mode 
as there may be data in the pipeline. 


3. Warning during transfer: 


(a) 


Resume after receiving warning status: 


RECORD nN = == > 
<{-<----- STATUS (WARNING) 
CONTINUE (RESUME) ----~-- > (INTERRUPT) 
RECORD n+l -—----> | 
Or 
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which 


(b) To terminate the access after a warning, follow sequence 
2(a) above to purge the output file or 2(b) to keep the 
output file. 


NOTE 


After sending the warning Status 
message, the accessed process issues no 
more receives until it receives an 
interrupt Continue Transfer message 
instructing it what to do. 


4. Stopping a sequential file storage operation before it is 
complete and purging the incomplete file on the accessed 


system: 
RECORD De== >= Sss23sS-= > 
ACCOMP (PURGE) ------- > Purge the incomplete file 


<----ACCOMP (RESPONSE) 


To save an incomplete file on the accessed . system, the 
operations are as in Step l. 


5. Checksum error on close: 


Record N----> 
ACCOMP (CLOSE) ----> 

<----STATUS (Checksum error) 
ACCOMP (CLOSE/ PURGE) ----> 

<----ACCOMP (RESPONSE) 


The user can either keep or purge the erroneous output file 
by sending either a close or purge Access Complete message 
without the CHECK field. 


5.2.3 Record Retrieval - Record retrieval requires that a Cuntrol 
message (with a record key for random retrieval) be sent by the 
accessing process for each record accessed. To specify record 
retrieval, the accessing process sets sequential record access, keyed 
access or Record File Address (RFA) access in the Control message. 
Block mode transfer, similar to record retrieval, is specified by 
setting Virtual Block Number (VBN) access. 


For keyed, VBN, or RFA access, the sequence is as follows: 


CONTROL (get record with Key n)----> , 
<---- RECORD n, STATUS 


‘CONTROL (get record with Key m)----> 
<---- RECORD m, STATUS 
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For sequential record access, the state operation is as follows: 
CONTROL (get sequential) --------- > 
<---- RECORD k, STATUS 


CONTROL (get sequential) -------- > 
_ €---- RECORD k+1, STATUS 


Once the location of a particular record in a file is found uSing 
random access, the user frequently wants to get subsequent records 
sequentially. To do this, switch the access mode from keyed or RFA to. 
sequential in the Control message, and issue a Get. (With RMS 
systems, the user is free to switch access modes according to the RMS 
rules.) 


CONTROL (get record with Key r)----> 


<----RECORD r, STATUS 
CONTROL (get Sequential) = -------- > 
<----RECORD r+l, STATUS 


Once a particular record in a file is found, it is possible _ to 
transfer the remainder of the file in sequential file access mode. 


CONTROL (get record with key t)----> 
<----RECORD t, STATUS 
CONTROL (Sequential file access, get) ----- > 
<----RECORD t+l, STATUS 
<----RECORD t+2, STATUS 


to end-of-file 


Error handling for sequential record retrieval is Similar to error 
handling for sequential file retrieval. The handling of warnings is 
easier, however. In order to continue processing, the accessing 
process sends a Control (Get). A Contine Transfer (Resume) is not 
necessary, but should be ignored if received. 


Error handling for random record retrieval is similar to that for 


seguential file retrieval. However, the Continue (Skip) recovery 
option, which is valid for sequential retrieval, is not valid for 
random retrieval. When a control request specifies a nonexistent | 


record while doing random record retrieval, the accessed process will 
return an appropriate error message (for example, record number out of 
range or record not found). 


5.2.4 Record Store - This is similar to sequential file store in 
messages exchanged. The access message specifies whether to open an 
existing file or create and open a new file. The Control message must 
specify Put access. For record storage, the accessing process may 
specify sequential record access, or keyed access. Optionally, VBN 
access may also be used. 


For relative files, the data messages must include the relative record 
number field specifying the number of the record (RECNUM). For hashed 
files where the user is supplying his own hash code (RBSHSH set in the 
ROP field of a Control message), RECNUM contains the hash code. In 
all other cases, the contents of RECNUM are ignored and will probably 
be set null to minimize data transmission overhead. For sequential 
files, records are written starting at the current position within the 
file. 
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The sequence of records to be stored may be preceded by a Control 
(Put) message if it is necessary to change record options or access 
mode from the current value. Optionally, each record to be stored may 
be preceded by a Control (Put) message. This is inefficient, however, 
Since it doubles the number of DAP messages transmitted. When storing 
a record, if the Data message is preceded by a Control message that 
contains a record number in the KEY field and the Data message also 
contains a record number in the RECNUM field, then the record number 
in the RECNUM field will be used. 


The sequence for record storage with return of status is as follows: 


RECORD n -------- > 
{-------- STATUS 

RECORD n+l ------ > 
(-------- STATUS 


Section 5.2.2 describes error-handling. Note that a warning Status 
message requires an interrupt Continue Transfer (Resume) (or Abort) to 
restart processing because of possible pipelining problems. Continue 
(Skip) causes the accessed process to ignore the record which caused 
the error and go on to process the next DAP message. 


5.2.5 Append to Existing File - The append operation is identical to 
Sequential store and applies only to sequential files. The accessed 
system places the records at the logical end of the file. The Control 
message sets the position to EOF. The sequence is as follows: 
RECORD l]-------- > 
{-------- STATUS 
RECORD 2-------- > 


(-------- STATUS 


5.2.6 Deleting a File - The delete operation (Erase) does not cause 
any file data to be transferred, but does manipulate file structures. 
Deleting a file does not require an Attributes message in the setup 
sequence. 


The message sequence for the delete operation is as follows: 


[ATTRIBUTES---------- >] 
ACCESS (ERASE) ----- > 
<<>> ACCOMP (RESPONSE) 
OF 
<-SSS= STATUS 
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5.2.7 Command/Batch Execution Files - The Data Access Protocol 
includes commands for the transfer and submission of files to a batch 


processing facility or command interpreter. | The © 
"submit-as-command-file" request in the Access message requests the 
storage of the data that follows in a temporary file. This request 


also indicates submission of the file to a batch-type facility upon 
access completion (closing of the file). The batch facility deletes 
the file following execution. DAP does not respond to any feedback 
from the batch facility. DAP does not guarantee that the file 
actually executes in the batch monitor. DAP transfers the file uSing 
sequential file storage (Section 5.2.2). 


The "execute-as-command-file" requests the submission of the specified 
file to the batch facility only. No data follows this command. The 
specified file is previously established on the accessed system. The 
file is not deleted following execution by the batch facility, so that 
the sequence "Store," and "execute-command-file" will transfer a file, 
Submit it and retain the file for later use. The sequence for 
"submit-as-command-file" is identical to "store," while the 
"execute-command-file" is identical to Erase. 


NOTE 


Since errors are not returned to the 
Originating node automatically, a test 
for errors might be included in indirect 
command files. Upon . error or 
completion, a suitable message can be 
returned to the originating node. 


5.2.8 Renaming a File - The rename operation does not cause the 
transfer of any file data. However, it does require the transmission 
of two file specifications. The old name of the file is in the Access 
message; the new name for the file is in the Name message following 
the Access message. Rename does not require an Attributes message in 
the set up sequence. 


The message sequence for the rename operation is as follows: 


[ATTRIBUTES] --------- > 
ACCESS (RENAME) ------ > 
NAME (FILESPEC) ------ > 
<----------ACCOMP (RESPONSE) 
or 
(eeesoesess STATUS 


5.2.9 Extending Files - File systems often offer an automatic file 
extension facility to extend an existing file when space runs out but 
there is more data to be written to the file. However, automatic file 
extension usually offers little control over the size and placement of 
file extensions. 


1G. 


Another method of extending a file is to use the explicit SEXTEND code 
of the Control message where a file system Supports user directed 
extension. User directed file extension iS initiated after the file 
is open. The DAP state operations are: 


data traffic on link 


ALLOC 1 ------ > 

ALLOC n ------ > 

CONTROL (EXTEND) ------ > 
(se = ALLOC 1 
.S-Se5= ALLOC n 
(eS Se5 STATUS 


continue data traffic on link 


Precede the Control (Extend) message by one or more ALLOC (Allocation 
Attributes Extension) messages Specifying the type of extension 
desired. Return a corresponding number of ALLOC messages, specifying 
the extensions performed. Return a Status message terminating the 
String of returned ALLOC messages. If an error occurs, a Status 
message will contain the error code. 


5.2.10 Display Attributes - This command provides a means of 
obtaining attribute information about a file. It is specifically for 
use with RMS file systems. If this command is used, the accessing 
node must specify which groups of attributes it wants. It does this 
by setting the appropriate bits in the DISPLAY field of the Control 
message sent to the remote node. In the case of the allocation and 
key definition groups of attributes, the appropriate Key Definition 
and Allocation Attributes Extension messages precede the Control 
message to indicate for which Keys of reference or which areas 
attributes are required. 


77 


The state operations for display are: 


[ATTRIBUTES 
EXTENS ION----~--------- > 
MESSAGES] 
CONTROL (Display) ------> 
feeserese= [ATTRIBUTES and ATTRIBUTES EXTENSION 
MESSAGES AS REQUIRED] 
Osea Seaeee STATUS 


5.2.11 Directory List - A directory or multiple directory listing 
request causes the accessed process to return the file attributes of 
the files specified in the FILESPEC field of the Access message 
requesting the directory list. The accessed process’ returns 
attributes using the Attributes and Attributes Extension messages. 
The accessing process can specify which Attributes messages it wants 
by setting the appropriate bit(s) in the DISPLAY field of the Access 
message. If the DISPLAY field requests the Name message (bit 8), the 
resultant file name is returned with the Attributes messages in a Name 
message. This Name message iS in addition to the Name messages shown 
in the state operations below. 


The file specification in the Access message may contain such "wild 
cards" as are recognized by the accessed process. 


As can be seen from the state operations for directory list below, a 
Name message for the file the Attributes messages describe precedes 
each group of Attributes messages. If no bits in the DISPLAY field of 
the requesting Access message are set, only the Name messages are sent 
(no Attributes messages). A Name message precedes all the files in a 
given directory. Optionally, if all the directories for which a 
listing is requested do not reside on the same volume-set (or 
Structure), a Name message precedes the directories for each 
volume-set. The Name message indicates which volume-set the following 
directories are on. | 


The state operations for directory listing are: 


ACCESS (DIRECTORY) ~----------- > 
[<---------- NAME (VOLUME-SET) ] 
{---------- NAME (DIRECTORY) 
{---------- NAME (FILE) 
[<----------ATTRIBUTES] 
[<---------- ATTRIBUTES EXTENSION] 
[<---------- ATTRIBUTES EXTENSION] 
(----------- NAME (FILE) 
[<---------- ATTRIBUTES] 
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[<== -32-S= ATTRIBUTES EXTENSION] 


[(<asSSS4——5= ATTRIBUTES EXTENSION] 


(SSeS ee NAME (FILE) 
{<---------- ATTRIBUTES] 

[ase SSeS ATTRIBUTES EXTENSION] 
[<----------ATTRIBUTES EXTENSION] 
(SS=Sse=>S5= NAME (DIRECTORY) 

(Sas pSSeanSee ACCOMP (RESPONSE) 


The accessing process may terminate a directory listing at anytime by 
Sending an Access Complete(Close). This causes the accessed process 
to send no more Name or Attributes messages, to finish its operation 
(for example, close any files it may have open) and finally to return 
an Access Complete(Response). Note that due to pipelining, the 
accesSing process may receive several Attributes and/or Name messages 
before receiving an Access Complete(Response) after it sends an Access 
Complete (Close). 

Errors occurring during a directory listing result from trying’ to 
obtain information to generate either a Name message or an Attributes 
or Attributes Extension message when reading a directory or _ the 
attributes of a file. On a gross level, errors will be either read 
errors, access protection violations, or non-existent attributes (for 
some reason, the attributes for a file cannot be found or do not 
exist). Read errors are handled by using the Continue Transfer (Try 
again or Skip) or Access Complete (Close). Protection violations and 
non-existent attributes errors are handled using the Continue Transfer 
(Skip) or Access Complete (Close). Continue Transfer (Try again) 
usually just returns the same error. 


Access Complete (Close) terminates the directory listing, closes any 
open files and leaves the link in a state where another DAP access may 
be started. Continue Transfer (Try again) repeats the operation that 
failed. Continue Transfer (Skip) causes the accessed process to skip 
over the operation causing the error, and attempt to recover the 
listing that lost some information. For example, this operation tries 
to read subsequent blocks in the directory, trying to get the next 
file name. Or the operation may attempt to read the next block 
containing attributes for the current file. In some cases, it may not 
be possible to recover uSing Continue Transfer (Skip). 
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The following are examples showing error handling for 
listing: | 


1. Using Access Complete(Close) to terminate listing: 


(---------- NAME (FILE) 

(---------- ATTRIBUTES 

(---------- STATUS 
ACCOMP(CLOSE) = ~==-------- > 

(---------- ACCOMP (RESPONSE) 


directory 


2. Using Control(Skip) to skip over error (some information will 
always be lost and in some cases it may not be possible to 


recover): 


(a) Error on reading file name: 


(---------- NAME (FILE) 


{(---------- ATTRIBUTES 
{---------- STATUS 
CONTROL(SKIP) 3 ------ > 
{-4-------- NAME (of next file) 


(b) Protection violation on reading file attributes 


| €se-------- NAME (FILE) 
(---------- STATUS 
CONTROL (SKIP) ae taste ee a on 
{eee ere NAME (of next file) 


| 
i 


(c) Unable to recover after error: 


(eaneaaeaa= NAME (FILE) 
<---------- ATTRIBUTES 
<---------- STATUS 
CONTROL (SKIP) eee eaere 
, (eS eesaS= STATUS (can not 
recover) 
ACCOMP (CLOSE) eee . 
: <---------- ACCOMP (RESPONSE) 
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5.2.12 Rewind Data Stream - SREWIND sets the current context of the 
Stream identified by the STREAMID field of the Control message to 


beginning of file (BOF). The state operations for rewind are: 
CONTROL (REWIND) ------ > 
Ca STATUS 


5.2.13 Truncate File - STRUNCATE truncates sequential files and is 
not a valid operation on other file types. 


It causes the deletion of all records from the current record on, and 
the declaration of an EOF in place of the current record. 


CONTROL (TRUNCATE) ------ > 


SSeS STATUS 


5.2.14 Free Buckets - SFREE unlocks all locked records in the stream 
identified by the STREAMID field of the Control message. 


CONTROL ( FREE) ------ > 


CSS os STATUS 
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5.2.15 Space Forward or Backward - S$SPACE forward or backward spaces 
the file the number of blocks specified in the KEY field. 


CONTROL (Forward/Backward) ------ > 


Pes STATUS 


The RECNUM field of the Status message contains the number of blocks 
actually spaced. This may not be the same as the number of blocks 
specified in the Control message. For example, if the current 
position is VBN 7, a backspace of 1@ will not actually backspace 
beyond the beginning of file. 


5.2.16 Flush 1/O Buffers - SFLUSH writes out all modified I/O buffers 
associated with the record access stream identified by the STREAMID of 
the Control message. 


CONTROL (FLUSH) ------ > 


(S-S=s= STATUS 


5.2.17 Deleting a Record - SDELETE deletes the current record for 
these files where record deletion is possible. For example, relative 
or indexed files usually Support record deletion. 


Ss S5 STATUS 
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5.2.18 Find - SFIND operation is essentially identical to SGET except 
that it does not transfer any data. The specified record becomes the 
current record. 


CONTROL (FIND) ------ > 


(=—S==— STATUS 


5.2.19 Update - SUPDATE causes the current record to be updated with 
the record in the following Data message on this stream. The 
Control(Update) and Data messages together form a transaction and must 
not have any intervening messages on that Stream. For convenience and 
efficiency, they can be blocked together. The operation is: 


CONTROL (UPDATE) ----- > 
DATA wee > 


C===e> STATUS 


Because of the transaction nature of update, if an error occurs at any 
point in the operation, the whole transaction fails. If the accessed 
process detectS an error in the Control message, it sends’ the 
appropriate Status message and it also discards the next Data message 
on that stream as it was a part of the transaction that failed. The 
accessing process recovers by starting the transaction over (having 
corrected the error) with new Control and Data messages as below: 


CONTROL (UPDATE) ----- > (error detected) 
DATA 7 ——— =e > (discard) 
<----- STATUS (with error code) 
Corrected 
CONTROL (UPDATE) ----- > 
DATA ee > 
(ee - STATUS (Successful) 
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If an error is detected in the Data message, the accessed process 
returns the appropriate Status message and considers the whole 
transaction to have failed (current position may be lost depending on 
the nature of the error -- it may be necessary to re-establish the 
current position in the file). After correcting the error in the Data 
message, the accessing process must repeat the entire transaction: 


CONTROL (UPDATE) ----- > 
DATA — =-=== > (error detected) 
| ¢<----- STATUS (with error code) 
CONTROL (UPDATE) ----- > 
Corrected 
DATA -----> 
CSS STATUS 


5.2.20 Wildcard Operations - The wildcard operation for sequential 
file retrieval, file deletion, file renaming and command file 
execution is Supported through the DAP message sequences defined in 
the following subsections. The wildcard file specification contained 
in the Access message is in the format used on the accessed system. 


NOTE 


It is not necessary to specify wildcard 
support in the Configuration message in 
order to use wildcards with the 
directory list function. Directory list 
support implies wildcard support for 
directory list file specifications. 
However, wildcard support must be 
specified in order to use wildcards with 
any function other than directory list. 
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5.2.20.1 Wildcard Sequential File Retrieval - Wildcard sequential 
file retrieval operation is Similar to sequential file retrieval as 
described in Section 5.2.1 except that Name messages and file 
attributes precede each transferred file. The state operations for 
wildcard sequential file retrieval are (optional Attributes Extension 
messages are not shown): 


ATTRIBUTES 9 -eeeH--------- > 
ACCESS (WILDCARD) -------------- > 
ree eas NAME (VOLUME-SET) ] 
Se NAME (DIRECTORY) ] 
aaa Bee ee | NAME (FILE) 
ae eee ey ATTRIBUTES 
(ae es eae ACK 
CONTROL (CONNECT) -------------- > 
aaa ACK 
CONTROL (GET) -------------- > 
aa te DATA 
ara aed DATA 
Cae ee DATA 
ae es ee STATUS (EOF) 
KCCOMP: (CLOSE)  =e2eseeeeecue— 5 
Sr re NAME (FILE) 
[Sean ATTRIBUTES 
eaters es ACK 
CONTROL (CONNECT) -------------- > 
(=== Sea as ACK 
CONTROL (GET) 29 --------------- > 
See toa es Ste DATA 
ag eae ae STATUS (EOF) 
ACCOMP (CLOSE) #§ <#sH5ssseeee—u > 
Seu eepaa steerer NAME (FILE) 
aa ---- ATTRIBUTES 
Crisis Peter ACK 
CONTROL (CONNECT) -------------- > 
a a laa ACK 
CONTROL (GET) -#------------ > 
ere eret ee DATA 
a aaa ai DATA 
a na aa als STATUS (EOF) 
ACCOMP (CLOSE) ~~ -------------- 5 
eee ea ACCOMP (RESPONSE) 


A new Name message for the volume-set or directory is sent only when 
either the volume-set or directory change. 
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If the accessing process does not want one of the files specified by 
the wildcard file specification, it closes the file instead of 
establishing a data stream thus skipping the file. 


Kaenn--------- NAME (FILE) 
{(------------- ATTRIBUTES 
(a------------ ACK 

ACCOMP (CLOSE) = «+==-=-=---~----- > 
{------------- NAME (of next file) 


If, during a file transfer, the accessing process decides it does not 
require the remainder of the file but wants to go on to the next file, 
the accessing process terminates the access to the current file with 


an Access Complete(Close). The accessed process closes the current 
file and initiates the transfer of the next file in the wildcard 
series. Note that due to pipelining, the accessing process may 


receive several Data messages or a Status message before the Name 
message. 


(nace aeann--- NAME (FILE) 

KP See ATTRIBUTES 

Coe ee ACK 
CONTROL (CONNECT) ------~-~--~---- > 

(eee Sa ae ACK 
CONTROL (GET) -------------- > 

Cena ss Bee DATA 

Seer ae ere ee DATA 

5 ae a a at DATA 
ACCOMP (CLOSE) © 9 -+------------ > 

Soa aa ae NAME (FILE) 

CA Sete a ATTRIBUTES 

(eneehcine SSe6e ACK 
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The accessing process may abort a wildcard file retrieval at anytime 
by disconnecting the link. When the accessed process detects link 
termination, it closes any currently open files. 


Sa aca a NAME (FILE) 

a ara ca ATTRIBUTES 

ae ae Na as ACK 
CONTROL (CONNECT) -------------- 5 

Sarees ses ACK 
CONTROL (GET) 2 29 -------------- > 

are aa DATA 


disconnect link 


Errors for wildcard sequential file retrieval are handled as_ with 
normal file retrieval except for errors in closing the file (excluding 
checksum errors). In this case Access Complete (Skip) forces’ file 
closure and clears the link so the accessed process can proceed to the 
next file to be transferred. 


ACCOMP. (CLOSE) ~seaeesteetes= : 
yee sees STATUS 
ACCOMP: (SKIP) =e emecSeefacs e 
Pee nen a NAME (next file). 
en ee ATTRIBUTES 
Or 
ACCOMP: (CLOSE): - eeteseeas- i 
[ee ene STATUS 


disconnect link 


5.2.20.2 Wildcard File Deletion - Wildcard file deletion has _ two 
modes of operation: 


1. Normal. Delete all files specified by the wildcard 
specification before returning any response (except error) to 
the accessing process. 


2. GoO/No-Go. Return the name of each file meeting the wildcard 
file specification to the accessing process before deleting 
the file. The accessing process can then cause the file to 
be deleted by sending a Control (Resume) message or the file 
to be left in the file system by sending a Control (Skip) 
message. Setting bit 4 in the ACCOPT field of. the Access 
message specifies the Go/No-Go mode of operation. 
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The operation of normal wildcard file deletion is: 


ACCESS (WILDCARD) ---------------> | 
(-------------- ACCOMP (RESPONSE) 


Operation of Go/No-Go wildcard file deletion is: 


ACCESS (WILDCARD) 3--37----------- > 
[<-------------- NAME (VOLUME) ] 
[<-------------- NAME (DIRECTORY) ] 
(-------------- NAME (FILE) 
CONTROL (RESUME) 3-------------- > (delete file) 
| fee eee nn------- NAME (FILE) 
CONTROL (SKIP) sosteaeteaetnteatertataatentatmetentanten > (do not delete) 
(-------------- NAME (FILE) 
CONTROL (RESUME) alaatneehastentastentententetentestont a (delete file) 
Vaeeesecesseees NAME (FILE) 
CONTROL (RESUME) -------------- > (delete file) 
{-------------- ACCOMP (RESPONSE) 


Abort Go/No-Go wildcard file deletion by disconnecting the link. 


ACCESS (WILDCARD)  -~---~------- > 
[<--~---------- NAME (VOLUME) ] 
[<------------- NAME (DIRECTORY) ] 
(a----------~+- NAME (FILE) 
CONTROL (RESUME) ~------------> 
(2-----------~- NAME (FILE) 


disconnect link 


Use the Continue Transfer message to handle errors in wildcard file 
deletion. Either retry the deletion that caused the error or skip the 
file causing the error. Alternatively, abort the operations by 
disconnecting the link. The operation of error handling (with 
Go/No-Go) is: 


ACCESS (WILDCARD) salenientndetenintestetadenteteel? a 
[<------------- NAME (VOLUME) ] 
[<------------- NAME (DIRETORY) ] 
(------------- NAME (FILE) 
(------------- STATUS 
CONTROL (TRY AGAIN)  ------------- > (Repeat operation) 
or 


88 


(aa anne ae NAME (FILE) 


Co haeateeatentnahestentesteeaien STATUS 
CONTROL (SKIP)  —- w#we een nnn > (Skip file) 
(err e een NAME (of next file) 
CONTROL (RESUME)  ------------- > (delete next file) 
OL 
(nnn - NAME (FILE) 
{------- STATUS 


disconnect link 


The operation of error handling without the Go/No-Go option is 
identical to that with Go/No-Go except that once the error has been 
dealt with, the Control (Resume) 1S not required as in the above 
sequence. The operation without Go/No-Go is as follows: 


ACCESS (WILDCARD) ------------- > 
[<------------- NAME (VOLUME) ] 
[<------------- NAME (DIRECTORY) | 
(------------- NAME (FILE) 
(------------- STATUS 
CONTROL (TRY AGAIN) 3------------- > (Repeat operation) 
Or 
(------------- NAME (FILE) 
(------------- STATUS 
CONTROL (SKIP) « -------==---- > (Skip file) 
Or 
(-----4------- NAME (FILE) 
(------------- STATUS 


disconnect link 


NOTE 


Go/No-Go operation can also be used with 
Single file delete. Setting bit 4 of 
ACCOPT requests this option. 


5.2.20.3 Wildcard File Rename - Wildcard file rename operation is 
identical to wildcard file deletion except that a second file 
Specification must be supplied as for normal rename (see section 
Deel oy) 4 This affects only the set-up as shown below (using Go/No-Go 
operation): 


ACCESS (WILDCARD) ---~------~------ > 

NAME (WILDCARD) alenteatententantantentestentambeteaded 
So tetentertentertententetnatentententen NAME (OLD VOLUME) } 
[<----------- NAME (OLD DIRECTORY) ] 
{-------~~----- NAME (OLD FILE) 

CONTROL (RESUME) £--------------- > (rename file) 
{-------------- ACCOMP (RESPONSE) 


In other respects, wildcard rename operation is identical to wildcard 
delete. - 
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5.2.20.4 Wildcard Command File Execution - Wildcard command file 
execution operation is identical to wildcard file deletion operation. 


5.3 Closing a File and Terminating Data Streams 


The Access Complete End of Stream (EOS) command terminates a data 
Stream. When the accesSing process wishes to terminate a data stream, 
it may do so by sending an Access Complete (EOS) containing the 
STREAMID it wishes to terminate. This will not close the file even if 
it terminates the last active data stream. 


An Access Complete (Close) closes the file and terminates the access. 
This includes closing out all remaining active data streams. 


5.4 Terminating a Logical Link 


Terminate the logical link by issuing a Disconnect Request. During 
the setup of the link, this may be done by the accessed process if 
optional timers indicate delay by the accessing process in supplying 
the required information. Once setup is complete, the accessing 
process controls the rate of access of the file. Disconnection at 
this point usually follows access completion. The accessing process 
may disconnect at any time; however, different systems may handle 
file closing and disposition differently if disconnection occurs 
during transfers. | “y = : 


The accessing process iS not required to disconnect and reconnect 
following each access. However, if a new access is to be started, it 
must be initiated in a timely manner. If a timer is being’ used 
between setup messages, it should also be set by the accessed process 
following an Access Complete message. : 


5.5 File Security, Integrity and Protection 


5.5.1 Access Control —- DAP attempts to provide approximately the same 
degree of file security and protection over the network as is 
available locally. To do this, a DAP user must be a registered user 
of each system holding files he wishes to access. Embedded in the 
connect message sent by the accessing process is sufficient 
information for the user to be logged onto the system that has files 
he wishes to access. User access is first verified (not necessarily 
actually logged-on) and then file access is allowed to proceed under 
the normal rules for file access applicable to a local user. 


If the accessing process wants to change the account under which. the 


accessed process is running at the remote node, it must disconnect the 
logical link and reconnect specifying the new account in the connect. 
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5.5.2 Data Integrity - A checksum on all data transferred (in both 
directions) during a file access can be generated by both the 
transmitting and receiving node to ensure data integrity. If this 
optional checksum is required, a bit in the ACCOPT field of the Access 
message is set. The accessing and accessed DAP processes compute the 
checksum on the data in the DAP Data message whenever a Data message 
1s sent or received. When the access is complete and the remote file 
is being closed, the checksum generated by the accessing process is 
sent to the accessed process in the CHECK field of the Access Complete 
(Close) message. The accessed process compares the checksum it 
received with the checksum it generated and closes the file if they 
agree. If they do not agree, a Status message is returned to the 
accesSing process instead of an Access Complete (Response). If a 
checksum error occurs, the accessing process can either purge the 
output file or, if errors can be tolerated, keep and close the output 
file (Sections 5.2.1 and 5.2.2) by sending the appropriate Access 
Complete message without the CHECK field. Checksum errors’ should be 
logged by the accessing process (and optionally by the accessed 
process). 


The checksum is a CRC computed only on the data in DAP Data messages. 
Data message headers are not included. The CRC polynomial is: 


Ree LG ae RES Ke a oe RE. ae OEE 2 ee OK ae 


Before Starting data transfer, initialize the 16-bit CRC to -l. In 
other words, set all bits. 


5.6 DAP-Based Applications Written by DIGITAL 


DAP message types 128 through 191 are reserved for DEC-written 
applications based on DAP that require further application-specific 
messages in the protocol. FTS is an example of such an application. 
It reguires the USERID message defined in Appendix A to supply 
accounting and access control information to the remote FTS- server 
process. 


5.6.1 Access Control and Accounting for DAP-Based Applications - The 
User Identification message is designed for use by applications using 
cooperating, DAP-Speaking control processes to offer a file transfer 
based service to network users. One of the control processes is a 
queueing process that handles the user’s requests for file transfer, 
and the other iS a server process that handles the remote end of 
executing the users” transfers. These control processes 
Characteristically establish a link and sequentially transfer several 
users’ files over the same link. The server control process runs as a 
privileged process. It has access to all files within the system. 


This scheme places the responsibility for access control (a user 
Should be allowed to access only those files he has explicit 
permission to access) and accounting (charge each user for the 
resources he uses) on the cooperating control processes. The control 
processes are charged for the resources they use as they are logged on 
the systems they are running on. They need to pass the charges on to 
the users of the services. In order to perform access control _ and 
accounting functions, the server process needs the user’s 
identification and optional account number. The User Identification 
message (see Appendix A) supplies this information. 


OL 


Note that security is not an issue here. The server process "trusts" 
the gqueueuing process and assumes that the contents of the User 
Identification messages are correct and any necessary validation has 
been done by the queueing process. Therefore a password is not 
necessary or even desirable in this message. The server process can 
"trust" the queueing process as long as it is talking to a valid 
queueing process. This is ensured by the Session Control access 
control procedure which validates a password supplied by the queueing 
process before it allows a logical link to be established. 
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APPENDIX A 


USER IDENTIFICATION MESSAGE 


The User Identification message is an application message designed for 
use by DIGITAL’s File Transfer System (FTS) and other DAP-based 
applications using the same queueing model. This queueing model 
consists of two controlling processes which speak DAP across the 
network. One of the processes accepts and queues requests from users 
to transfer files. The other is a server process which executes the 
user’ S requests at the remote node in response to DAP messages’ from 
the first process. A single logical link may be used to sequentially 
process any number of uSer requests. It iS not necessary to 
disconnect the link after processing each user’s file transfer 
request. 


In order that appropriate access control and accounting meaSures' can 
be taken by the server process, the queueing control process sends a 
User Identification message each time it initiates a file access for a 
new user. The User Identification contains the identity (for example, 
PPN) under which the access at the remote node takes place plus the 
optional user account number. The USer Identification message is sent. 
immediately before the Attributes message when initiating a new file 
access. The form of the message is: 


USERID | IDMENU | IDENT| ACCOUNT | OPTIONS 


where: 
USERID : The operator field with TYPE = 128. 
IDMENU(EX-6) : BM The following bit map specifies which of the 
following fields are present in this message. 
If the field is not present, the default, if 
any, should be used. These fields and only 
these fields may appear in the message and they 
must appear in the order specified. 
Meaning (When Set) 
IDENT 
ACCOUNT 
OPTIONS 
IDENT(I-40) : A The user identification (for example, UIC) under 
which the server process will execute the 
following remote file accesses. This 


establishes the user's identity for both 
resource uSage accounting at the remote node and 
file access rights. If this field is defaulted, 
the previous identity in effect remains in 
effect. When a link is first established, the 
user identity from the Session Control connect 
message is the user identity in effect. 


“ 


93 


ACCOUNT (I-40) 


OPTIONS (I-132) 


e 
e 


« 


A 


USER IDENTIFICATION MESSAGE 


For systems requiring additional information for 
accounting (for example, discrete project 
number) this field contains this accounting 
information. 


Options field for additional information which 
may be required by the server control process. 
It may be used for supplemental accounting 
information, page headers, or, non-network 
routing information for mail. 
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APPENDIX B 


REVISION HISTORY 


B.1 Version 1.9 to Version 4.1 

A number of significant changes have been made to the Data Access 
Protocol since its first release. The major differences between DAP 
Version 4.1 and Version 1.0 are: | 


@ DAP Version 1.@ could not adequately support indexed and ISAM 
file access. 


e The format of the operator field has been expanded. 
e The User Identification message has been eliminated. 
e The Status and Error messages have been combined. 

e The Access Complete message has been added. 

e The Configuration message has been added. 


e The two types of Data messages employed in Version 1.@ have 
been merged into one Data message in Version 4.1. 


While a definite incompatibility exists between Versions 1.@ and 4.1, 
numerous steps have been taken to build a more flexible architecture. 
DAP Version 4.1 is flexible enough to allow new file access functions 
to be added to the protocol framework. 


B.2 Version 4.1 to Version 5.6 


A number of Significant changes have been made to DAP since the 
Version 4.1 release. The major differences are as follows: 


e The Key Definition, Allocation, Summary, Date and Time, 
Protection, and Name messages have been added. Previously 
some of these were present but were marked reserved. 


e The format of the operator field has been expanded again to 
allow blocking of DAP messages greater than 256 bytes long and 
to allow an optional field in the Data message. 


e A file transfer checksum on the complete file has been added 
for better file integrity. 


e Indexed file access is now fully supported. Only record 
number random access was Supported in 4.1. 


e The Configuration message has been expanded to include more 
capabilities. 


22 


REVISION HISTORY 


Print file carriage control has been added. 


The Image data type definition has been clarified, especially 
for files containing non 8-bit bytes. 


The MACY11 data type has been added. 


Explanation of how to use the Extended Attributes messages has 
been added. 


Rename has been added. 
Display and Directory List have been added. 
Several new Control message options have been added. 


Wildcard support has been added. 


The 5.6 version of DAP is upwardly compatible with the 4.1 version. 


The new 


facilities in 5.6 have been put into the protocol using 


extensibility built into DAP Version 4.1. 
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REVISION HISTORY 


GLOSSARY 


bucket 


A grouping of a file’s virtual blocks used for I/O transfer or 
structural format storage. 


ISAM 
Indexed Sequential Access Method. This access method is a 
combination of random and Sequential access. Random access is 
used to locate a sequence of records and then access is switched 
to sequential to read the remaining records in the series. 

JEN 
Job File Number. The JFN is the job’s global handle on a file. 

key 
A data item used to locate a record in a random access file 
system. 

key field 


For direct and indexed files, the position of the key within the 
record. 


key of reference 
The particular key field of the record for which the key applies. 
MACY11 


A format for fitting 16-bit words into 36-bit words for file 
transfers between PDP-l1l’s and DECsystem 1@’s and 20s. 


octets 


Octets in this document are bytes of 8 bits, with bit @ the 
rightmost (low-order, least-significant) bit and bit 7 the 
leftmost (high-order, most-sSignificant) bit. Fields and bytes of 
other lengths are numbered similarly. 


object type 
Numeric value that may be used for process addressing by DECnet 
processes instead of a process name. See the Session Control 


specification for further details. DAP server processes. are 
object type number 21 (octal). 
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RFA 


RMS 


URD 


VBN 


wild 


REVISION HISTORY | 


Record File Address. The unigue address of a record within a 
file. This method of addressing can be used explicitly with RMS. 


Record Management Services. This file system will be used on all 
major DIGITAL systems except where Space is limited (for example, 
RT-11). In addition to access modes provided by previous’ file 
systems, RMS provides random access for direct and indexed files 
and ISAM. | 


Unit Record Device. 


Virtual Block Number. This number is in the range 1 to n where n 
is the highest numbered block allocated to the file. 


card 
An asterisk (*) that replaces an element in a file specification. 
The asterisk specifies all known items in the range indicated by 


its position. For example, FILE.*;* specifies all known versions 
and types of all files named FILE. 
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